.NET आंशिक वर्ग बनाम विरासत

Question

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

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

क्लासिक विरासत, जहां पूरे बात एक एकल, "अखंड" वर्ग में किया जाता है और उपभोक्ताओं के आधार कार्यान्वयन ओवरराइड करने के लिए स्वतंत्र हैं:

तो, वहाँ दो दृष्टिकोण जो मन में छलांग है। यह समय-समय पर मुश्किल हो जाता है, हालांकि, और अक्सर कास्टिंग सिरदर्द पेश करता है। इसके अलावा, यदि व्युत्पन्न वर्ग सावधान नहीं है और बेस क्लास कार्यक्षमता का आह्वान करना भूल जाता है, तो चीजें जल्दी से घबरा सकती हैं।

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

यहां आपके लिए मेरा प्रश्न है: जब आप इस तरह के परिदृश्य से निपट रहे हैं (यदि आपके पास कभी है), या यदि आपको इस तरह के परिदृश्य के साथ प्रस्तुत किया गया था, तो आप किन समाधानों पर विचार करेंगे, और क्यों?

Answer 1

संपूर्ण कारण आंशिक कक्षाएं नेट में शामिल हैं। कोड जनरेशन टूल का उपयोग करना आसान बनाना है।

यदि आप कोड उत्पन्न कर रहे हैं, तो आंशिक कक्षाओं का उपयोग करें। यह वास्तव में इतना आसान है। आप जोखिम को क्यों ले लेंगे कि कोड को सड़क से फिर से उत्पन्न किया जा सकता है और आपको अनुकूलन के साथ इसे फिर से अपडेट करने के लिए एक टन काम करना होगा?

मुझे नहीं लगता कि आंशिक रूप से बहुत जटिलता है - यह केवल एक वर्ग कई फाइलों पर विभाजित है। एक फ़ाइल में जेनरेट कोड, दूसरे में कस्टम कोड।

Answer 2

मैं आंशिक कक्षा पथ जाऊंगा। सिर्फ इसलिए कि यह कई हिस्सों में 1 ऑब्जेक्ट को विभाजित करने के लिए अधिक प्राकृतिक फिट बैठता है। यहां तक ​​कि Linq2Sql आंशिक का उपयोग करता है। पैटर्न और उचित सम्मेलनों के साथ जटिलता के साथ लड़ो। और आंशिक कक्षाओं पर 'आंशिक अद्यतन' (यदि उत्पन्न कोड अच्छी तरह से संरचित है) निष्पादित करना आसान है।

यदि आप कोई कोड उत्पन्न नहीं कर रहे हैं - कक्षा विरासत के रास्ते पर जाएं (वास्तव में, आपको मजबूर होना होगा, क्योंकि आंशिक अलग-अलग असेंबली में काम नहीं करेंगे)।

Answer 3

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

Answer 4

यदि आपके पास एक प्रकार है जो धारावाहिक (xml) होना है और कुछ कार्यक्षमता जोड़ना चाहते हैं, तो आपको आंशिक वर्ग का उपयोग करना होगा, न कि विरासत। धन्यवाद /// एम

Answer 5

आप कहते हैं:

(लेकिन नहीं काफी बिल्कुल) की तरह एक ORM

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