क्या टी 4 कोड और अधिक बनाने के लिए वहां कुछ भी है ... साफ?

Question

मेरे पास एक टी 4 टेम्पलेट में भरने वाली काफी जटिल चीज है। मूल रूप से मैं बहुत तरह

{= foo =} अधिक पाठ की तरह कुछ ले ...

और यह एक वर्ग (देखें) में तब्दील:

public class MyView 
{ 
    public string foo{get;set;} 
    public string Write() 
    { 
    return foo+@" more text..."; 
    } 
} 

उत्पन्न कोड है निश्चित रूप से इससे अधिक जटिल। वैसे भी, टी 4 टेम्पलेट अभी कोड की 600 लाइनों से अधिक है और वास्तव में अप्रबंधनीय तेज़ बन रहा है। मेरा मानना ​​है कि मुख्य समस्या कोड और "सामग्री" मिश्रण (यानी, स्थिर कोड) है। मुझे सच में यकीन नहीं है कि इस समस्या को कैसे ठीक से ठीक किया जाए (हालांकि निश्चित रूप से उत्पन्न कोड को प्रभावित नहीं करते)। मुझे टी 4 निष्पादन त्रुटियों के परीक्षण के अलावा, मेरे टी 4 कोड का परीक्षण करने के लिए यूनिट का कोई व्यवहार्य तरीका भी नहीं दिखता है। और निश्चित रूप से इसके जेनरेट कोड का परीक्षण करने का लगभग असंभव कार्य प्रतीत होता है।

क्या कोई भी "मॉडल-व्यू" प्रकार फ्रेमवर्क या तकनीक है जिसका उपयोग मैं अपने टी 4 टेम्पलेट कोड को और अधिक साफ करने के लिए कर सकता हूं?

Answer 1

लंबी यात्रा के बाद, मैंने अंततः अपने टी 4 टेम्पलेट्स के पहले यूनिट परीक्षणों में चेक किया। असल में, मैंने जो किया वह "व्यू" (वास्तविक टी 4 टेम्पलेट), और "तर्क" (कोड को उत्पन्न करता है, लेकिन वास्तव में इसे आउटपुट नहीं करता है और टी 4 पर भरोसा नहीं करता है)

I फिर इसे एक कदम आगे बढ़ाया और इसे बनाने के लिए एक बड़ा hack का उपयोग किया ताकि मेरी तर्क फ़ाइल टी 4 के बाहर संकलित हो। इसका निर्माण करने का अच्छा प्रभाव पड़ा ताकि इंटेलिजेंस और कंपाइलर त्रुटियां काम कर सकें। यह मुझे परियोजना को संदर्भित करके यूनिट परीक्षणों से मेरी लॉजिक क्लास तक पहुंचने देता है।

मैंने कोड उदाहरणों (पहले/बाद) के साथ एक लेख लिखा और उदाहरण इकाई परीक्षण on my blog, यदि आप इसे कैसे करना है, इस बारे में लंबा विवरण चाहते हैं।

Answer 2

IMHO दो सबसे महत्वपूर्ण अवधारणाओं जटिल टेम्पलेट्स लेखन जब

1. मॉडल और देखने अलग है - यह एक न्यूनतम (अक्सर रखरखाव समस्या का एक कारण) के लिए टेम्पलेट तर्क रखने में मदद करता। व्यक्तिगत रूप से मुझे नहीं लगता कि इसे एक ढांचे की आवश्यकता है, केवल यह आवश्यक है कि आप इसे करें।
2. आंशिक आपका मित्र है - मैं सामान्य रूप से मॉडल से कंकाल कोड उत्पन्न करने के लिए टी 4 का उपयोग करता हूं। विशिष्ट व्यवहार मॉडल में डालने के प्रयास के लायक नहीं हो सकता है, अक्सर आंशिक कक्षाओं या विधियों के उपयोग के माध्यम से उस व्यवहार को अनुमति देने के लिए बेहतर होता है।

के रूप में महत्वपूर्ण है, लेकिन अच्छा नहीं

1. बनाओ कोड खोजा - मैं आदेश नेविगेट करने में IntelliSense की कमी के साथ, क्योंकि मैं उनमें से कोई भी काफी अच्छा लगता है टी -4 के ऐड-ऑन पर भरोसा नहीं करते, कोड मुझे कोड खोजने योग्य बनाना है। कॉलम प्रॉपर्टी नाम को कॉल करने के बजाए यह उतना आसान हो सकता है, मैं इसे कॉलमनाम कहता हूं।
2. आउटपुट में "टैग" डालें - आउटपुट के उस हिस्से को उत्पन्न करने वाले कोड को ढूंढना आसान बनाता है।

उदाहरण अलग मॉडल/दृश्य:

<# 
    // Model for Dependency Pooperties 
    Model = new [] 
    { 
     new ClassDefinition ("MyDataGrid") 
      { 
       P ("CultureInfo"   , "CultureInfo"), 
       P ("Pen"     , "CellBorderPen"), 
       P ("IEnumerable<object>" , "Rows"), 
       C ("WColumnDefinition"  , "Columns"), 
      }, 
    }; 
#> 
// Include the view 
<#@ include file="..\T4\DependencyProperties.ttinclude" #> 

दृश्य तो मॉडल पर दोहराता और निर्भरता गुण उत्पन्न करते हैं।

निर्भरता गुण के व्यवहार तो आंशिक तरीके के रूप में लागू किया जाता है

partial void Changed_Columns(
     ObservableCollection<WColumnDefinition> oldValue, 
     ObservableCollection<WColumnDefinition> newValue 
     ) 
    { 
     HookUpColumns(oldValue, null); 
     HookUpColumns(newValue, this);    
    } 

ध्यान दें कि मॉडल में इस विशिष्ट व्यवहार डाल काफी मॉडल को मुश्किल होगा।

अंत में; एक सक्षम प्रोग्रामर के लिए मेटाप्रोग्राम को सक्षम रूप से लिखने में भी समय लगता है।इससे पहले कि मैं एक शैली में पहुंचे, इससे मुझे कई प्रयास हुए, जो मुझे विश्वास है कि यह बरकरार है लेकिन मेरे लिए यह प्रयास के लायक था क्योंकि मैं गुणवत्ता को तेजी से भेज सकता हूं।

मुझे उम्मीद है कि यह मदद करता है ...

पीएस। मुझे नहीं लगता कि कोई भी तर्क देगा कि टी 4 कभी भी सुरुचिपूर्ण है लेकिन फिर भी यह उपयोगी है।