कोड जनरेटर या टी 4 टेम्पलेट्स, क्या वे वास्तव में बुराई हैं?

Question

मैंने लोगों को यह सुना है कि कोड जेनरेटर और टी 4 टेम्पलेट्स का उपयोग नहीं किया जाना चाहिए। इसके पीछे तर्क यह है कि यदि आप जनरेटर के साथ कोड उत्पन्न कर रहे हैं तो जेनरिक और टेम्पलेटिंग के माध्यम से कोड बनाने के लिए एक बेहतर और अधिक प्रभावी तरीका है।

जबकि मैं उपर्युक्त इस कथन से थोड़ा सहमत हूं, मुझे वास्तव में टेम्पलेट बनाने के प्रभावी तरीके नहीं मिल पाए हैं जो उदाहरण के लिए स्वयं कह सकते हैं। Otherwords में मैं क्या कर सकते हैं कभी नहीं:

return new T(); 

साथ ही, यदि मुझे लगता है मैं ने पाया है कि टी -4 टेम्पलेट के साथ संयोजन के रूप में Microsoft.SqlServer.Management.SMO का उपयोग कर कोड के बड़े पैमाने पर मात्रा में पैदा करने पर अद्भुत किया गया है डेटाबेस मूल्यों पर आधारित कोड जनरेट करना चाहते हैं कॉपी करने के लिए बिना/पेस्ट या resharper का उपयोग करें।

जेनिक्स के साथ मुझे मिली कई समस्याएं भी हैं कि मेरे सदमे में ऐसे कई डेवलपर हैं जो उन्हें समझ में नहीं आते हैं। जब मैं समाधान के लिए जेनेरिक की जांच करता हूं, ऐसे समय होते हैं जहां यह जटिल हो जाता है क्योंकि सी # कहता है कि आप ऐसा कुछ नहीं कर सकते जो मेरे दिमाग में तार्किक लग सकता है।

आपके विचार क्या हैं? क्या आप जनरेटर बनाना पसंद करते हैं, या आप जेनेरिक का उपयोग करना पसंद करते हैं? इसके अलावा, जेनेरिक कितने दूर जा सकते हैं? मैं जेनेरिकों के बारे में एक सभ्य राशि जानता हूं, लेकिन ऐसे जाल और नुकसान हैं जो मैं हमेशा उस टी 4 टेम्पलेट का सहारा लेता हूं।

परिदृश्यों को संभालने का अधिक उचित तरीका क्या है जहां आपको बड़ी मात्रा में लचीलापन की आवश्यकता है? ओह और इस सवाल के लिए बोनस के रूप में, सी # और जेनेरिक पर अच्छे संसाधन क्या हैं?

Answer 1

आप नया टी() कर सकते हैं; यदि आप यह

public class Meh<T> 
    where T : new() 
{ 
    public static T CreateOne() 
    { 
    return new T(); 
    } 
} 

कोड जनरेटर के लिए करते हैं। मैं बिना किसी समस्या के हर दिन एक का उपयोग करता हूं। मैं वास्तव में वास्तव में एक का उपयोग कर रहा हूं :-)

जेनिक्स एक समस्या हल करते हैं, कोड जनरेटर दूसरे को हल करते हैं। उदाहरण के लिए, एक यूएमएल संपादक का उपयोग करके एक व्यापार मॉडल बनाना और फिर अपनी कक्षाओं को दृढ़ता कोड के साथ उत्पन्न करना, क्योंकि मैं हर समय this tool का उपयोग करके जेनरिक के साथ हासिल नहीं किया जा सका, क्योंकि प्रत्येक निरंतर वर्ग पूरी तरह से अलग है।

जेनरिक पर एक अच्छे स्रोत के लिए। सबसे अच्छा Jon Skeet's book निश्चित रूप से होना चाहिए! :-)

Answer 2

अधिक कोड का अर्थ अधिक जटिलता है। अधिक जटिलता का अर्थ है कि बग को छिपाने के लिए और अधिक जगहें, जिसका अर्थ है चक्रों को लंबे समय तक ठीक करना, जिसका मतलब है कि पूरे परियोजना में उच्च लागत है।

जब भी संभव हो, मैं समान कार्यक्षमता प्रदान करने के लिए कोड की मात्रा को कम करना पसंद करता हूं; आदर्श रूप से कोड जनरेशन के बजाय गतिशील (प्रोग्रामेटिक) दृष्टिकोण का उपयोग करना। प्रतिबिंब, गुण, पहलू और जेनेरिक एक डीआरवाई रणनीति के लिए बहुत सारे विकल्प प्रदान करते हैं, जिससे पीढ़ी को अंतिम उपाय के रूप में छोड़ दिया जाता है।

Answer 3

शायद यह थोड़ा कठोर है, लेकिन मेरे लिए कोड पीढ़ी गंध करता है।

उस कोड जनरेशन का उपयोग किया जाता है इसका मतलब है कि कई अंतर्निहित सामान्य सिद्धांत हैं जिन्हें "खुद को दोहराएं" फैशन में व्यक्त किया जा सकता है। इसमें थोड़ी देर लग सकती है, लेकिन जब आप कक्षाओं के साथ समाप्त होते हैं तो यह संतोषजनक होता है जिसमें केवल उन बिट्स होते हैं जो वास्तव में बदलते हैं, जो कि बुनियादी ढांचे वाले बुनियादी ढांचे के आधार पर होते हैं।

जेनरिक के रूप में ... नहीं, मेरे पास इसके साथ बहुत अधिक समस्याएं नहीं हैं।एकमात्र चीज जो वर्तमान में काम नहीं करती है, कह रही है कि

List<Animal> a = new List<Animal>(); 
List<object> o = a; 

लेकिन यह सी # के अगले संस्करण में भी संभव होगा।

Answer 4

वास्तव में वास्तव में तेज़ी से कॉपी/पेस्ट करने में सक्षम क्यों है, इसे और अधिक स्वीकार्य बनाते हैं?

यह कोड जनरेशन के लिए एकमात्र औचित्य है जिसे मैं देख सकता हूं।

यदि जनरेटर आपको आवश्यक सभी लचीलापन प्रदान करता है, तब भी आपको सीखना होगा कि उस लचीलेपन का उपयोग कैसे करें - जो अभी तक सीखने और परीक्षण की एक और परत है।

और यदि यह शून्य समय में चलता है, तो भी यह कोड को फटकारता है।

मैंने अपना डेटा एक्सेस क्लास लॉन्च किया। यह कनेक्शन, लेनदेन, संग्रहीत प्रक्रिया पैरा आदि के बारे में सब कुछ जानता है, और मुझे केवल एक बार सभी एडीओ.NET सामान लिखना पड़ा।

अब यह बहुत लंबा रहा है क्योंकि मुझे इसमें एक कनेक्शन ऑब्जेक्ट के साथ कुछ भी लिखना था (या यहां तक ​​कि देखें), कि मुझे वाक्यविन्यास को याद रखने के लिए कड़ी मेहनत की जाएगी।

Answer 5

जेनिक्स और कोड जनरेशन दो अलग-अलग चीजें हैं। कुछ मामलों में आप कोड पीढ़ी के बजाय जेनेरिक का उपयोग कर सकते हैं और उन लोगों के लिए जो मुझे विश्वास है कि आपको चाहिए। अन्य मामलों के लिए कोड जनरेशन एक शक्तिशाली उपकरण है।

उन सभी मामलों के लिए जहां आपको बस कुछ डेटा इनपुट के आधार पर कोड उत्पन्न करने की आवश्यकता है, कोड जनरेशन जाने का तरीका है। सबसे स्पष्ट, लेकिन किसी भी तरह से एकमात्र उदाहरण विजुअल स्टूडियो में फॉर्म संपादक नहीं है। यहां इनपुट डिजाइनर डेटा है और आउटपुट कोड है। इस मामले में जेनेरिक वास्तव में कोई मदद नहीं है, लेकिन यह बहुत अच्छा है कि वीएस बस जीयूआई लेआउट के आधार पर कोड उत्पन्न करता है।

Answer 6

जेनरिक्स, टेम्पलेट्स और अन्य ऐसे शॉर्टकट जैसी कोड जनरेशन एक शक्तिशाली टूल है। और सबसे शक्तिशाली उपकरणों के साथ, यह अपने उपयोगकर्ता की क्षमता को अच्छे और बुरे के लिए बढ़ाता है - उन्हें अलग नहीं किया जा सकता है।

तो यदि आप अपने कोड जनरेटर को अच्छी तरह से समझते हैं, तो यह सब कुछ अनुमान लगाएगा, और क्यों, और वैध कारणों से ऐसा करने का इरादा रखते हैं, फिर उस पर है। लेकिन इसे किसी ऐसे स्थान से दूर करने के लिए (या किसी अन्य तकनीक) का उपयोग न करें जहां आप यह सुनिश्चित नहीं कर रहे हैं कि आप कहां जा रहे हैं, या वहां कैसे पहुंचे।

कुछ लोग सोचते हैं कि, यदि आपको अपनी वर्तमान समस्या हल हो जाती है और कुछ व्यवहार लागू होते हैं, तो आप सुनहरे होते हैं। यह हमेशा स्पष्ट नहीं होता है कि आप अगले डेवलपर के लिए अपने ट्रेल में कितना क्रूर और अपर्याप्तता छोड़ते हैं (जो स्वयं हो सकता है।)

Answer 7

जनरेटिंग कोड बुरा नहीं है और यह गंध नहीं करता है! कुंजी सही समय पर सही कोड उत्पन्न करना है। मुझे लगता है कि टी 4 बहुत अच्छा है - मैं इसे कभी-कभी इस्तेमाल करता हूं, लेकिन जब मैं ऐसा करता हूं तो यह बहुत उपयोगी होता है। कहने के लिए, बिना शर्त, कोड उत्पन्न करना बुरा है बिना शर्त पागल है!

Answer 8

ऐसा लगता है कि कोड जनरेटर तब तक ठीक हैं जब तक कोड पीढ़ी आपके सामान्य निर्माण प्रक्रिया का हिस्सा न हो, बल्कि एक बार चलाने के बजाए और उसके आउटपुट को बनाए रखें। मैं इस चेतावनी को जोड़ता हूं क्योंकि अगर कोड कोड जनरेटर का उपयोग केवल एक बार करें और इसे बनाए गए डेटा को त्याग दें, तो आप केवल एक बड़े पैमाने पर डीआरवाई उल्लंघन और रखरखाव सिरदर्द बना रहे हैं; जबकि प्रत्येक बार प्रभावी ढंग से कोड उत्पन्न करना मतलब है कि जो भी आप उत्पन्न करने के लिए उपयोग कर रहे हैं वह वास्तविक स्रोत कोड है, और जेनरेट की गई फ़ाइलें केवल मध्यवर्ती संकलन चरण हैं जिन्हें आपको अधिकतर अनदेखा करना चाहिए।

लेक्स और yacc उपकरण के क्लासिक उदाहरण हैं जो आपको कार्यक्षमता को कुशल तरीके से निर्दिष्ट करने और उससे कुशल कोड उत्पन्न करने की अनुमति देते हैं। हाथ से अपनी नौकरी करने की कोशिश करने से आपके विकास के समय में वृद्धि होगी और शायद कम कुशल और कम पठनीय कोड उत्पन्न होगा। और जब आप निश्चित रूप से अपने कोड में लेक्स और yacc जैसे कुछ को शामिल कर सकते हैं और संकलन समय के बजाय रन टाइम पर अपनी नौकरियां कर सकते हैं, तो निश्चित रूप से आपके कोड में काफी जटिलता जोड़ दी जाएगी और इसे धीमा कर दिया जाएगा। यदि आपको वास्तव में रन टाइम पर अपना विनिर्देश बदलने की ज़रूरत है तो यह इसके लायक हो सकता है, लेकिन अधिकांश सामान्य मामलों में संकलन समय पर आपके लिए कोड उत्पन्न करने के लिए लेक्स/yacc का उपयोग करना एक बड़ी जीत है।

Answer 9

कोड जनरेटर को कोड गंध माना जा सकता है जो लक्ष्य लैंगेज में त्रुटियों या कार्यक्षमता की कमी दर्शाता है।

उदाहरण के लिए, जबकि यह कहा गया है कि "ऑब्जेक्ट्स जो जारी रहती हैं उन्हें सामान्यीकृत नहीं किया जा सकता", यह बेहतर होगा कि "सी # में ऑब्जेक्ट्स जो स्वचालित रूप से अपने डेटा को जारी रखे, सी # में सामान्यीकृत नहीं किया जा सकता" क्योंकि मैं निश्चित रूप से विभिन्न तरीकों के उपयोग के माध्यम से पाइथन में कर सकता हूं।

पाइथन दृष्टिकोण, हालांकि ऑपरेटर [ ] (स्ट्रिंग के रूप में method_name) के उपयोग के माध्यम से स्थिर भाषाओं में नकल किया जा सकता है, जो आवश्यकताओं के आधार पर या तो एक मजेदार या स्ट्रिंग देता है। दुर्भाग्यवश यह समाधान हमेशा लागू नहीं होता है, और एक मजेदार वापस लौटना असुविधाजनक हो सकता है।

मैं जो बिंदु बना रहा हूं वह यह है कि कोड जनरेटर एक चुने हुए भाषा में एक दोष दिखाते हैं जो विशिष्ट समस्या के लिए अधिक सुविधाजनक विशेष वाक्यविन्यास प्रदान करके संबोधित किया जाता है।

Answer 10

कोड पीढ़ी मेरे लिए भाषा, ढांचे, आदि में मिली कई समस्याओं के लिए एक कामकाज है। वे खुद से बुरा नहीं हैं, मैं कहूंगा कि यह एक भाषा (सी #) और ढांचा जारी करने के लिए बहुत बुरी (यानी बुराई) है जो आपको & पेस्ट (गुणों पर स्वैप, घटनाओं को ट्रिगर करने, मैक्रोज़ की कमी) की प्रतिलिपि बनाने या जादुई संख्या (wpf बाध्यकारी) का उपयोग करने के लिए मजबूर करता है।

तो, मैं रोता हूं, लेकिन मैं उनका उपयोग करता हूं, क्योंकि मुझे करना है।

Answer 11

टी -4 के प्रवर्तक के रूप में, मैं इस सवाल का काफी कुछ समय की रक्षा के लिए के रूप में आप कल्पना कर सकते हैं :-)

मेरे विश्वास अपने सबसे अच्छे रूप कोड पीढ़ी पर उत्पादन के रास्ते पर एक कदम है कि है लिया है पुन: प्रयोज्य पुस्तकालयों का उपयोग कर समकक्ष मूल्य।

जैसा कि कई अन्य ने कहा है, डीआरवाई को बनाए रखने की मुख्य अवधारणा कभी भी जेनरेट कोड को मैन्युअल रूप से बदलती नहीं है, बल्कि स्रोत मेटाडेटा में परिवर्तन होने पर पुन: उत्पन्न करने की क्षमता को संरक्षित करने या कोड जेनरेटर में आपको एक बग मिलती है। उस बिंदु पर जेनरेट कोड में ऑब्जेक्ट कोड की कई विशेषताएं होती हैं और आप कॉपी/पेस्ट प्रकार की समस्याओं में भाग नहीं लेते हैं।

सामान्य रूप से, पैरामीटरकृत कोड जनरेटर (विशेष रूप से टेम्पलेट-आधारित सिस्टम के साथ) का उत्पादन करने के लिए यह बहुत कम प्रयास है, यह एक उच्च गुणवत्ता वाले बेस लाइब्रेरी को सही ढंग से इंजीनियर करने के लिए है जो उपयोग लागत को उसी स्तर तक ले जाता है, इसलिए यह एक स्थिरता से मूल्य प्राप्त करने और पुनरावृत्ति त्रुटियों को हटाने का त्वरित तरीका।

हालांकि, मुझे अभी भी विश्वास है कि समाप्त प्रणाली को कम कोड प्राप्त करके अक्सर सुधार किया जाएगा। यदि कुछ और नहीं है, तो इसकी स्मृति पदचिह्न लगभग हमेशा काफी छोटी होगी (हालांकि लोग इस संबंध में जेनिक्स के रूप में लागत मुक्त होने के बारे में सोचते हैं, जो वे निश्चित रूप से नहीं हैं)।

यदि आपको कोड जेनरेटर का उपयोग करके कुछ मूल्य पता चला है, तो यह अक्सर उत्पन्न कोडबेस से लाइब्रेरी को कटाई में निवेश करने के लिए आपको कुछ समय या धन या सद्भावना खरीदता है।फिर आप नई लाइब्रेरी को लक्षित करने के लिए कोड जनरेटर को क्रमशः पुन: प्रस्तुत कर सकते हैं और उम्मीद है कि बहुत कम कोड उत्पन्न करें। धोये और दोहराएं।

मेरे लिए एक दिलचस्प काउंटरपॉइंट बनाया गया है और यह इस धागे में आता है कि समृद्ध, जटिल, पैरामीट्रिक पुस्तकालय सीखने की अवस्था के मामले में सबसे आसान बात नहीं है, खासतौर पर उन लोगों के लिए जो मंच में गहराई से डूबे हुए नहीं हैं। सरल मूल ढांचे पर कोड पीढ़ी के साथ चिपकने से वर्बोज़ कोड उत्पन्न हो सकता है, लेकिन यह अक्सर पढ़ने के लिए काफी सरल और आसान हो सकता है।

बेशक, जहां आपके जनरेटर में बहुत भिन्नता और बेहद समृद्ध पैरामीटरकरण है, तो आप अपने टेम्पलेट्स में जटिलता के लिए अपने उत्पाद को जटिलता से दूर कर सकते हैं। यह स्लाइड करने के लिए एक आसान तरीका है और रखरखाव को उतना ही सिरदर्द बना सकता है - इसके लिए देखें।

Answer 12

उत्पन्न कोड की कॉपी/पेस्ट का प्रकार (ORMs बनाने की तरह) भी बहुत उपयोगी हो सकता है ...

आप अपने डेटाबेस बना सकते हैं, और फिर ORM में व्यक्त किया है कि डेटाबेस परिभाषा की एक प्रति उत्पन्न होने अपने पसंदीदा भाषा

लाभ तब आता है जब आप अपनी मूल परिभाषा (डेटाबेस) बदलते हैं, संकलन दबाएं और ओआरएम (यदि आपके पास कोई अच्छा है) परिभाषा की आपकी प्रतिलिपि को फिर से उत्पन्न कर सकता है। अब आपके डेटाबेस के सभी संदर्भों को कंपाइलर्स प्रकार चेकर द्वारा चेक किया जा सकता है और जब आप टेबल या कॉलम का उपयोग कर रहे हों तो आपका कोड संकलित करने में विफल रहेगा जो अब मौजूद नहीं है।

इस बारे में सोचें: यदि मैं अपने कोड में कुछ बार एक विधि कहता हूं, तो क्या मैं मूल रूप से इस विधि को दिए गए नाम का जिक्र नहीं कर रहा हूं? मैं उस नाम को दोहराता रहता हूं ... भाषा डिजाइनरों ने इस समस्या को पहचाना और समाधान के रूप में "टाइप-सुरक्षा" के साथ आया। प्रतियों को हटा नहीं रहा है (जैसा कि डीआरवाई सुझाव देता है कि हमें करना चाहिए), लेकिन इसके बजाय उन्हें सहीता के लिए जांचना।

ओआरएम जेनरेट कोड तालिका और कॉलम नामों का जिक्र करते समय एक ही समाधान लाता है। प्रतियां/संदर्भों को हटा नहीं रहा है, लेकिन डेटाबेस परिभाषा को आपकी (टाइप-सुरक्षित) भाषा में लाया जा रहा है जहां आप इसके बजाय कक्षाओं और गुणों का उल्लेख कर सकते हैं। कंपाइलर्स प्रकार की जांच के साथ, यह एक समान समस्या को इसी तरह हल करता है: जब आप पुरानी या गलत वर्तनी तालिकाओं (कक्षाओं) या कॉलम (गुण) का संदर्भ देते हैं तो रनटाइम के बजाय गारंटी संकलन-समय त्रुटियां।

Answer 13

उद्धरण: मुझे वास्तव में टेम्पलेट्स बनाने के प्रभावी तरीके नहीं मिल पाए हैं जो उदाहरण के लिए स्वयं कह सकते हैं। अन्य शब्दों में मैं कभी नहीं कर सकता:

नया टी() लौटाएं;

public abstract class MehBase<TSelf, TParam1, TParam2> 
    where TSelf : MehBase<TSelf, TParam1, TParam2>, new() 
{ 
    public static TSelf CreateOne() 
    { 
     return new TSelf(); 
    } 
} 

public class Meh<TParam1, TParam2> : MehBase<Meh<TParam1, TParam2>, TParam1, TParam2> 
{ 
    public void Proof() 
    { 
     Meh<TParam1, TParam2> instanceOfSelf1 = Meh<TParam1, TParam2>.CreateOne(); 
     Meh<int, string> instanceOfSelf2 = Meh<int, string>.CreateOne(); 
    } 
} 

Answer 14

मैंने कोड पीढ़ी और जेनरिक के लिए टी 4 का उपयोग किया है। दोनों अच्छे हैं, उनके पेशेवर और विपक्ष हैं, और विभिन्न उद्देश्यों के लिए उपयुक्त हैं।

मेरे मामले में, मैं डेटाबेस स्कीमा के आधार पर इकाइयों, डीएएल और बीएलएल उत्पन्न करने के लिए टी 4 का उपयोग करता हूं। हालांकि, जेएलएक्स और रिफ्लेक्शन के आधार पर डीएएल और बीएलएल ने मिनी-ओआरएम बनाया है। इसलिए मुझे लगता है कि जब तक आप नियंत्रण में रहते हैं और इसे छोटा और सरल रखते हैं, तब तक आप उन्हें एक तरफ उपयोग कर सकते हैं।

टी 4 स्थिर कोड उत्पन्न करता है, जबकि जेनरिक गतिशील है। यदि आप जेनेरिक का उपयोग करते हैं, तो आप प्रतिबिंब का उपयोग करते हैं जिसे "हार्ड-कोडेड" समाधान से कम प्रदर्शन करने वाला कहा जाता है। बेशक आप प्रतिबिंब परिणाम कैश कर सकते हैं।

के बारे में 'नई टी() वापसी, ", मैं इस तरह गतिशील तरीके का उपयोग करें:

public class ObjectCreateMethod 
    { 
    delegate object MethodInvoker(); 
    MethodInvoker methodHandler = null; 

    public ObjectCreateMethod(Type type) 
    { 
     CreateMethod(type.GetConstructor(Type.EmptyTypes)); 
    } 

    public ObjectCreateMethod(ConstructorInfo target) 
    { 
     CreateMethod(target); 
    } 

    void CreateMethod(ConstructorInfo target) 
    { 
     DynamicMethod dynamic = new DynamicMethod(string.Empty, 
        typeof(object), 
        new Type[0], 
        target.DeclaringType); 
     ILGenerator il = dynamic.GetILGenerator(); 
     il.DeclareLocal(target.DeclaringType); 
     il.Emit(OpCodes.Newobj, target); 
     il.Emit(OpCodes.Stloc_0); 
     il.Emit(OpCodes.Ldloc_0); 
     il.Emit(OpCodes.Ret); 

     methodHandler = (MethodInvoker)dynamic.CreateDelegate(typeof(MethodInvoker)); 
    } 

    public object CreateInstance() 
    { 
     return methodHandler(); 
    } 
} 

फिर, मैं इसे इस तरह कहते हैं:

ObjectCreateMethod _MetodoDinamico = new ObjectCreateMethod(info.PropertyType); 
object _nuevaEntidad = _MetodoDinamico.CreateInstance(); 

Answer 15

क्या है का एक अच्छा प्रतिशत कोड पीढ़ी के बिना विजुअल स्टूडियो 2010 संभव नहीं होगा। इकाई फ्रेमवर्क संभव नहीं होगा। एक फॉर्म पर नियंत्रण खींचने और छोड़ने का सरल कार्य संभव नहीं होगा, न ही लिंकक होगा। यह कहने के लिए कि कोड पीढ़ी का उपयोग नहीं किया जाना चाहिए अजीब है क्योंकि बहुत से लोग इसके बारे में सोचने के बिना इसका इस्तेमाल करते हैं।