इकाई की रूपरेखा Pocos - कोड गंध

Question

दूर करने के लिए मैं Repository और Unit of Work पैटर्न के साथ इकाई की रूपरेखा मॉडल-सबसे पहले उपयोग कर रहा हूँ की जरूरत नया स्वरूप, खजाने एफई Pocos लौट आते हैं।

मुझे लगता है कि मैं नहीं तो मेरे कोड अब XyzService जो एक अलग इकाई की रूपरेखा के लिए व्यापार तर्क को लागू करने वर्ग Xyz POCO उत्पन्न है जैसी चीजों से भरा है मेरी Pocos कि इकाई की रूपरेखा द्वारा उत्पन्न कर रहे करने के लिए व्यवहार जोड़ सकता है, ग्रहण किया।

मैं निम्नलिखित प्रश्न हैं:

1. यह एक बुरा कोड गंध के रूप में न केवल मैं एफई Pocos है, मैं हर POCO के लिए एक सेवा है। कई वर्गों के अलावा, व्यावसायिक तर्क व्यापार इकाई के बाहर विभाजित है। क्या यह एनीमिक विरोधी पैटर्न का एक उदाहरण है?

2. यदि मैं ईएफ के साथ चिपक जाता हूं, तो क्या कोई तरीका है कि मैं व्यवहार (यानी आंशिक कक्षाओं के माध्यम से) या अन्य माध्यमों को जोड़ सकता हूं?

3. लगातार अज्ञान पैटर्न को देखते हुए जो डेटा परत (हमारे मामले में एक भंडार) से रिटर्न बिजनेस इकाइयों का उपयोग करते हैं, अगर मैं EF-MODEL -> REPOSITORY-DAL -> BIZ-ENTITY से जाना चाहता हूं तो मुझे लगता है कि व्यापार इकाई के बीच दो तरह के मैपिंग होंगे और ईएफ मॉडल पीओसीओ। क्या ऑटोमैपर जैसे यूटिलिटीज ने नेस्टेड ऑब्जेक्ट्स के जटिल रिश्तों को गहन रूप से संभाला है जिनकी मुझे संभावना है?

4. डुप्लिकेटेड व्यावसायिक संस्थाओं को उनके समकक्ष ईएफ मॉडल इकाइयों के साथ कम करने के लिए, क्या मैं ईएफ को हटाने और प्रत्येक रिपोजिटरी के लिए LINQ से SQL का उपयोग करके अपने स्वयं के भंडार कार्यान्वयन को बेहतर नहीं लिखूंगा?

5. कोई भी अनुशंसित तरीका जो मुझे कोड पर ध्यान केंद्रित करने की अनुमति देता है (ईएफ मॉडल पर पहले तय करने के बजाए लक्ष्य के बजाय), फिर भी अंत में इकाई फ्रेमवर्क का उपयोग करें जब मैं दृढ़ता परत लिखने के लिए तैयार हूं, लेकिन ऐसा करने में बहुत सारे अतिरिक्त काम और मैपिंग से परहेज करना? ईएफ कोड-पहले इस संबंध में बेहतर होगा?

मैं अन्य प्रौद्योगिकियों कि विकास सहायता कर सकते हैं (उदाहरण के लिए NHibernate) तो कृपया उल्लेख करने के लिए स्वतंत्र लग रहा है की कुछ और याद किया है।

Answer 1

1. हाँ, Fowler के अनुसार, यह एक विरोधी पैटर्न है। मुझे व्यक्तिगत रूप से इस विरोधी पैटर्न को आक्रामक नहीं लगता है, लेकिन कुछ लोग करते हैं। यहां सबसे अच्छा निर्णय का प्रयोग करें। अगर यह गलत लगता है और इससे निपटने में दर्द होता है, तो इसे बदलें।
2. Yes। आंशिक वर्ग इस के साथ मदद कर सकते हैं। आप जो आंशिक लिखते हैं उनमें व्यवहार कर सकते हैं।
3. Yes, ऑटोमैपर स्वचालित रूप से नेस्टेड ऑब्जेक्ट्स से निपटेंगे यदि उनके पास मैपिंग सेटअप
4. फिर से, यह आपके ऊपर है। यदि ईएफ आपको पागल कर रहा है, तो इसका इस्तेमाल न करें। उपयोग करते समय क्या काम करता है और आप क्या अच्छा महसूस करते हैं इसका उपयोग करें।
5. Code first बिल्कुल इस के लिए बनाया गया था।

Answer 2

1. यह है, लेकिन यह दृष्टिकोण फायदे के बिना नहीं है। उदाहरण के लिए, पीओसीओ और व्यापार तर्क के बीच अलगाव लागू करने से उस तर्क को निर्भर किया जा सकता है और निर्भरता इंजेक्शन या किसी अन्य माध्यम के माध्यम से आपूर्ति की जा सकती है।

2. ध्यान रखें कि आंशिक वर्गों कई विधानसभाओं अवधि नहीं कर सकते हैं (MSDN से):

   सभी आंशिक प्रकार परिभाषाएँ एक ही प्रकार के कुछ हिस्सों में एक ही विधानसभा और एक ही मॉड्यूल में परिभाषित किया जाना चाहिए (होना .exe या .dll फ़ाइल)। आंशिक परिभाषा एकाधिक मॉड्यूल नहीं फैल सकती है।

   यह प्रतिबंध अवांछित हो सकता है, हालांकि आप आवश्यक व्यवहार को लागू करने के लिए विस्तार विधियों का उपयोग कर सकते हैं।

3. मैंने ऑटोमैपर का उपयोग नहीं किया है, इसलिए रयान की सलाह यहां लागू होगी।

4. & 5. मैंने इन्हें एक साथ समूहित किया है क्योंकि कोड-फर्स्ट का उपयोग आपके विशिष्ट भंडार कार्यान्वयन पर असर डालेगा। यदि आपने कोड-फर्स्ट की कोशिश नहीं की है, तो मैं इसे देखने की सलाह देता हूं।

भंडारों के संदर्भ में, मेरी वरीयता भंडार के लिए उन सभी पीओसीओ प्रकारों के संदर्भ में पूरी तरह से सामान्य होने के लिए है, जिनके साथ हम काम कर रहे हैं, और संचालन उपलब्ध हैं। उदाहरण के लिए, LINQ के साथ एक रिपोजिटरी में Get विधि हो सकती है जो किसी दिए गए Expression<Func<T, bool>> के आधार पर आइटम पुनर्प्राप्त करती है (कहें, IEnumerable<T> के रूप में)।

मुझे यह दृष्टिकोण पसंद है क्योंकि यह भंडार को इंजेक्शन पर निर्भर करता है, मानक सीआरयूडी संचालन को अधिक डोमेन-विशिष्ट लोगों से अलग करता है, फिर भी उपभोक्ताओं/व्युत्पन्न कक्षाओं से कोड पुन: उपयोग के लिए महान अवसर प्रदान करता है।

Answer 3

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

"कोड फर्स्ट" के साथ आपके पास अपने पीओसीओ पर बहुत अधिक नियंत्रण होता है, और डाटाबेस-माइग्रेशन जैसे कई अतिरिक्त लाभ, और टी 4 टेम्पलेट्स और इसी तरह की पसंद के साथ पीओसीओ को मचान करने की क्षमता।

मैं LinqToSQL पर वापस नहीं जाऊंगा, ईएफ अधिक सुविधा युक्त है और इसका उज्ज्वल भविष्य है, आईएमओ। ईएफ अब ओपन-सोर्स है, मेरे पास कुछ मुद्दों के साथ मदद करने के लिए स्रोत पर कुछ दिखने हैं।

Answer 4

डिजाइन पुस्तकें, पैटर्न पुस्तकें और प्रमुख ब्लॉगर्स ओके हैं, हालांकि हम डेवलपर्स को लगता है कि हमें अपनी परियोजनाओं को विकसित करना है क्योंकि वे सुझाव देते हैं कि जब भी वे किताबें/लेख हमें समझने के लिए पर्याप्त संदर्भ प्रदान नहीं करते हैं कि वे किस स्थितियों में समझते हैं आवेदन करें और जब वे नहीं करते हैं।

ऐसी सभी चीजों के लिए एक अच्छी तरह की डिज़ाइन जैसी कोई चीज़ नहीं है। मुझे लगता है कि आप तकनीकी बिंदुओं पर ध्यान केंद्रित कर रहे हैं और यह ठीक है लेकिन सबसे पहले आपको सबसे महत्वपूर्ण प्रश्न का जवाब देना चाहिए: क्या आपकी आवश्यकताओं को उस डिजाइन के साथ अच्छी तरह से फिट करना चाहिए?

याद रखें, आपके पास अन्य विचारधाराओं के बीच आवश्यकताएं, बाधाएं, संसाधन और समय है, जो आपको अपने व्यापार को मार्गदर्शन करने के लिए कुछ व्यापार-बंदों में शामिल होने के लिए मजबूर करता है।

उदाहरण के लिए:

• तुम सच में डेटा संग्रह स्थान की आवश्यकता है? ईएफ का उपयोग करके सीधे आप अपनी संस्थाओं को क्या प्राप्त करते हैं?
• क्या आपको डेटामोडल्स और बिज़मोडल्स की आवश्यकता है? क्या होगा यदि आप केवल लेनदेन का उपयोग करें?
• क्या आपको यूओडब्ल्यू की आवश्यकता है? क्यूं कर? ईएफ आपके लिए यह बहुत अच्छी तरह से संभाल नहीं सकता है?
  :

इन सवालों के जवाब, कुछ पूर्ण नहीं कर रहे हैं वे अपनी आवश्यकताओं पर निर्भर करते हैं, समय, हिलना, आदि

अब, मैं आपको बता दूँ कि मैं क्या आपके प्रश्नों के बारे में सोचते हैं

हां, यह कुछ कारणों से खराब गंध करता है: ए) पीओसीओ ऑब्जेक्ट्स होना चाहिए, ठीक है ... पोको, यह बीक्यूज है कि आपके पास बिज़-ऑब्जेक्ट है, बेशक, तर्क है लेकिन ... किस प्रकार का तर्क करता है पीओसीओ वस्तुओं में है?

हाँ, आंशिक कक्षाओं का उपयोग आपके xyzService के बजाय इसके लिए किया जाना चाहिए। यह स्पष्ट है और क्योंकि आपके xys सेवा कोई सेवाएं नहीं हैं!

हाँ, ऑटोमैपर मैपिंग समस्या से निपट सकता है। हालांकि, यह उस समस्या को ठीक नहीं करता है जिसमें आपके पास शायद बहुत सारे मैपिंग हैं। दोबारा, अगर आपको इसकी ज़रूरत नहीं है, तो उनसे बचें।

क्या आप (या आपकी कंपनी) के पास पैसा और समय है जो ऐसा करने के लिए पर्याप्त है? आजकल कोई भी पूरी तरह से मजबूत कारण के बिना ओआरएम से बचता है। तो, नहीं, यह मत करो!

इडेम 4.

यह मेरी राय है।