क्या डीटीओ प्लस यूनिटऑफवर्क पैटर्न एक वेब अनुप्रयोग के लिए एक डीएएल डिजाइन करने के लिए एक अच्छा दृष्टिकोण है?

Question

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

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

1. क्या यह वेब अनुप्रयोग के डीएएल को डिजाइन करने का सही दृष्टिकोण है? क्यूं कर?
2. यदि आपने "हाँ" को 1 का उत्तर दिया है, तो इसे यूनिटऑफवर्क पैटर्न के साथ डीटीओ की अवधारणा को कैसे सुलझाया जा सकता है?
3. यदि आपने "नहीं" का उत्तर दिया है, जो वेब अनुप्रयोग के लिए डीएएल डिज़ाइन करने का सही दृष्टिकोण हो सकता है?

यदि संभव हो, तो कृपया अपने उत्तर का समर्थन करने वाली ग्रंथसूची दें।

वर्तमान डिजाइन के बारे में:

आवेदन तीन परतों पर विकसित करने की योजना कर दिया गया है प्रस्तुति, व्यापार और दाल। बिजनेस लेयर में दोनों facades और सेवाएं

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

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

कंक्रीट भंडार केवल प्राप्त करना चाहिए और .NET प्रकार और डीटीओ वापस करना चाहिए।

अब हम इस समस्या का सामना कर रहे हैं: बनाने के लिए जेनेरिक विधि संलग्न इकाइयों के लिए एक अस्थायी या लगातार आईडी उत्पन्न नहीं करती है (जब तक हम SaveChanges() का उपयोग नहीं करते हैं, इसलिए लेनदेन को तोड़ना चाहते हैं); इसका मतलब यह है कि बीएल में डीटीओ को जोड़ने के लिए सेवा विधियों का उपयोग नहीं किया जा सकता है)

Answer 1

यहां कई चीजें चल रही हैं ... मुझे लगता है कि धारणा यह है कि आप 3-स्तरीय आर्किटेक्चर का उपयोग कर रहे हैं। उस ने कहा, मैं आपके द्वारा किए गए कुछ डिज़ाइन निर्णयों पर स्पष्ट नहीं हूं और उन्हें बनाने के लिए प्रेरणा क्या थी। आम तौर पर, मैं कहूंगा कि आपका ऑब्जेक्ट कॉन्टेक्स्ट आपके वर्गों में चारों ओर पारित नहीं होना चाहिए। कनेक्शन प्रबंधन को संभालने वाले कुछ प्रकार के प्रबंधक या भंडार वर्ग होना चाहिए। यह आपके डीबी राज्य प्रबंधन मुद्दे को हल करता है। मुझे लगता है कि एक रिपोजिटरी पैटर्न वास्तव में यहां अच्छा काम करता है। वहां से, आप कार्यस्थल की इकाई को काफी आसानी से कार्यान्वित करने में सक्षम होना चाहिए क्योंकि आपका कनेक्शन प्रबंधन एक ही स्थान पर संभाला जाएगा।यह देखते हुए कि मैं आपके वास्तुकला के बारे में क्या जानता हूं, मैं कहूंगा कि आपको एक पीओसीओ रणनीति का उपयोग करना चाहिए। पीओसीओ का उपयोग करने से आप किसी भी ओआरएम प्रदाता को कसकर जोड़ नहीं सकते हैं। लाभ यह है कि आपके पीओसीओ आपके ऑब्जेक्ट कॉन्टेक्स्ट (शायद किसी प्रकार के रिपोजिटरी के माध्यम से) के साथ बातचीत करने में सक्षम होंगे और इससे आपको परिवर्तन ट्रैकिंग में दृश्यता मिल जाएगी। दोबारा, वहां से आप अपने व्यापार लेनदेन के व्यवहार के तरीके पर पूर्ण नियंत्रण देने के लिए कार्य इकाई (लेनदेन) पैटर्न को लागू करने में सक्षम होंगे। मुझे लगता है कि यह सब एक साथ फिट बैठता है यह बताने के लिए यह एक अविश्वसनीय रूप से उपयोगी लेख है। कोड बग्गी है लेकिन सटीक रूप से आपके द्वारा वर्णित आर्किटेक्चर के प्रकार के लिए सर्वोत्तम प्रथाओं को दिखाता है: Repository, Specification and Unit of Work Implementation

प्रश्न संख्या 1 के मेरे उत्तर का संक्षिप्त संस्करण "नहीं" है। उपर्युक्त लिंक प्रदान करता है जो मैं मानता हूं कि आपके लिए बेहतर दृष्टिकोण है।

Answer 2

आपको यह देखना चाहिए कि dependency injection और सामान्य माध्यमों में नियंत्रण में उलटा होना चाहिए। इससे ObjectContext के जीवन चक्र को "बाहर से" नियंत्रित करने की क्षमता प्रदान की जाएगी। आप यह सुनिश्चित कर सकते हैं कि प्रत्येक http अनुरोध के लिए ऑब्जेक्ट संदर्भ का केवल 1 उदाहरण उपयोग किया जाता है। निर्भरता प्रबंधन मैन्युअल रूप से प्रबंधित करने से बचने के लिए, मैं एक कंटेनर के रूप में StructureMap का उपयोग करने की सलाह दूंगा।

एक और उपयोगी (लेकिन इसे सही करने के लिए काफी कठिन और कठिन) तकनीक दृढ़ता का अमूर्त है। सीधे ObjectContext का उपयोग करने के बजाय, आप Repository नामक उपयोग करेंगे जो आपके डेटा स्टोर के लिए एपीआई जैसे संग्रह प्रदान करने के लिए ज़िम्मेदार है। यह उपयोगी सीम प्रदान करता है जिसका उपयोग आप अंतर्निहित डेटा भंडारण तंत्र को स्विच करने या परीक्षणों के लिए पूरी तरह से दृढ़ता से बाहर निकलने के लिए कर सकते हैं।

जैसा कि जेसन ने पहले ही सुझाव दिया है - आपको POCO`s (सादे पुराने क्लियर ऑब्जेक्ट्स) का भी उपयोग करना चाहिए। इसके बावजूद कि इकाई ढांचे के साथ अभी भी अंतर्निहित युग्मन होगा, आपको अवगत होना चाहिए, यह जेनरेट किए गए वर्गों का उपयोग करने से कहीं बेहतर है।

चीज़ें जो आप कहीं और काफी तेजी से नहीं मिल सकता है:

1. कोशिश unit of work के उपयोग से बचने के लिए। आपके मॉडल को लेनदेन सीमाओं को परिभाषित करना चाहिए।
2. generic repositories (IQueryable के बारे में भी ध्यान दें) के उपयोग से बचने का प्रयास करें।
3. repository pattern name के साथ अपने कोड को स्पैम करना अनिवार्य नहीं है।

इसके अलावा, आप domain driven design पढ़ने का आनंद ले सकते हैं। यह जटिल व्यापार तर्क से निपटने में मदद करता है और कोड को कम प्रक्रियात्मक, अधिक ऑब्जेक्ट उन्मुख बनाने के लिए महान दिशानिर्देश देता है।

Answer 3

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

मुझे लगता है कि आपकी सबसे अच्छी शर्त आपके वास्तुकला में लेन-देन प्रबंधित करने की अपेक्षा करने के तरीके के बारे में कुछ और परिभाषा डालने में निहित है। ऑब्जेक्ट कॉन्टेक्स्ट का सम्मान करता है क्योंकि आपके नियंत्रक/सेवा में ट्रांज़ेक्शनस्कोप का उपयोग करना एक अच्छी शुरुआत है। बेशक आपको यह ध्यान रखना पड़ सकता है कि नियंत्रक/सेवाएं अन्य नियंत्रकों/सेवाओं को कॉल कर सकती हैं जिनमें लेनदेन है। उन परिदृश्यों की अनुमति देने के लिए जहां आप अपने व्यापार लेनदेन और बाद के डेटाबेस कॉल पर पूर्ण नियंत्रण चाहते हैं, आपको कुछ प्रकार की ट्रांज़ेक्शन मैनेजर क्लास बनाना होगा, जो आम तौर पर लेन-देन को ऊपर और नीचे प्रबंधित करता है।मैंने पाया है कि NCommon लेन-देन और प्रबंधन दोनों में असाधारण नौकरी करता है। वहाँ UnitOfWorkScope और TransactionManager कक्षाओं पर एक नज़र डालें। यद्यपि मैं यूनिटऑफवर्क पर भरोसा करने के लिए रिपोजिटरी को मजबूर करने के एनसीओमन के दृष्टिकोण से असहमत हूं, लेकिन यदि आप चाहें तो आसानी से प्रतिक्रिया प्राप्त की जा सकती है।

जहां तक ​​आपके persistantID मुद्दा चला जाता है, check this out

Answer 4

मैं हमेशा से यह मानना ​​है कि कोड चीज़ें बेहतर प्रोग्रामर के लिए दुनिया से व्याख्या कर सकते हैं। और यह विशेष रूप से इस विषय के लिए सच है। यही कारण है कि मैं आपको सलाह देता हूं कि आप जिस स्वीकृति को लागू कर रहे हैं, उसमें चुप्पी में महान नमूना आवेदन को देखने के लिए।

परियोजना कहा जाता है Sharp Architecture, यह MVC और NHibernate के आसपास केंद्रित है, लेकिन आप जब आपको उनकी आवश्यकता सिर्फ EF लोगों के साथ NHibernate भागों की जगह एक ही तरीकों का उपयोग कर सकते हैं। इस परियोजना का उद्देश्य वेब अनुप्रयोगों के निर्माण के लिए सभी समुदाय सर्वोत्तम प्रथाओं के साथ एक आवेदन टेम्पलेट प्रदान करना है।

यह सब आम को शामिल किया गया और असामान्य विषयों की सबसे जब ORM का उपयोग कर, लेनदेन के प्रबंधन, आदि आईओसी कंटेनर, DTOs की उपयोग करते हैं,

साथ निर्भरता के प्रबंधन और यहाँ एक sample application है।

मैं इसे पढ़ने और कोशिश करने पर जोर देता हूं, यह आपके लिए एक असली खजाना होगा जैसे यह मेरे लिए था।