मुझे जटिल ऑब्जेक्ट मॉडल के लिए रिपॉजिटरी पैटर्न कैसे लागू करना चाहिए?


21

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

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

क्या प्रत्येक ऑपरेशन के लिए एक UnitOfWork और प्रत्येक इकाई के लिए एक रिपॉजिटरी बनाना वास्तव में आवश्यक है? मैं हजारों वर्गों के साथ समाप्त हो सकता था। मुझे पता है कि यह अनुचित है, लेकिन मैंने जटिल मॉडल और यथार्थवादी व्यावसायिक अनुप्रयोगों पर रिपोजिटरी, कार्य की इकाई और इकाई ढांचे को लागू करने के लिए बहुत कम मार्गदर्शन पाया है।

जवाबों:


6

सबसे पहले, आप हर उस इकाई से गुजरेंगे जो आपके पास है और खुद से पूछें:

क्या इस इकाई को अकेले बनाए रखने का कोई मतलब है?

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

मुझे पसंद नहीं है कि उन्होंने आपके द्वारा दिए गए लिंक में UnitOfWork पैटर्न कैसे लागू किया। मैं आपको इन पंक्तियों के साथ कुछ और करने का सुझाव देता हूं । आपको प्रति वर्ग एक वर्ग को परिभाषित करने की आवश्यकता नहीं है। प्रत्येक रिपॉजिटरी के लिए एक ही वर्ग का उपयोग किया जा सकता है, प्रत्येक के पास ऑपरेशन के जीवनकाल के लिए UnitOfWork वर्ग का अपना उदाहरण है। आप एक ही UnitOfWork को विभिन्न रिपॉजिटरी में उन परिवर्तनों के लिए पुन: उपयोग कर सकते हैं जो आप एक ही समय में बनाए रखना चाहते हैं।


अच्छा लिंक! मैं इसकी जांच कर रहा हूं।
एरिक फल्सकेन

आपका लिंक (और उत्तर) सबसे अधिक उपयोगी था, हालांकि मैंने प्रदान किए गए पैटर्न का उपयोग नहीं किया। मैंने एक रैपर क्लास का उपयोग करके समाप्त किया, जो एक सामान्य रिपॉजिटरी के रूप में काम करने के लिए Add / Attach / Remove / SaveChanges विधियों को सम्‍मिलित करता है, और फिर एक क्वेरी / QuerySingle / QueryAll पद्धति जोड़ी जो मेरी क्वेरी कार्यान्वयन रखने के लिए किसी भी क्वेरी वर्ग को स्वीकार करती है। यह अच्छी तरह से काम कर रहा है ताकि मैं सीधे EF को शामिल किए बिना LINQ और T-SQL दोनों प्रश्नों को कर सकूं।
एरिक फल्सकेन

एंटिटी फ्रेमवर्क, लेनदेन के अपने उपयोग के साथ, पहले से ही कार्य पैटर्न की इकाई का कार्यान्वयन है।
ग्रेग बरगार्ड

1
लिंक मर चुका है ...
न्यूटोपियन

3

हो सकता है कि आपको Domain-Driven Design पर एक नजर डालनी चाहिए । यह एग्रीगेट्स में अपनी वस्तुओं को समूहीकृत करने और प्रत्येक एग्रीगेट की रूट इकाई के लिए रिपॉजिटरी बनाने की सिफारिश करता है। एक बड़े जटिल ऑब्जेक्ट मॉडल में ऑर्डर लाने का यह एक अच्छा तरीका है।

आपके विभिन्न क्रियात्मक क्षेत्र बाउंडेड कॉन्टेक्ट हो सकते हैं । ओवरलैपिंग बाउंडेड कॉन्टेक्ट्स से निपटने के लिए विभिन्न तकनीकें हैं यदि उनके बीच अलगाव स्पष्ट नहीं है।


0

"रिपॉजिटरी पैटर्न" डेटाबेस डिज़ाइन के लिए आपको कौन सी सैद्धांतिक नींव मिली है? मैं कोई नहीं अनुमान लगा रहा हूँ। यह एक फर्जी आधार पर आराम देने वाली जटिलता की एक परत है: "दृढ़ता की परत" जो आप से अलग होने की आवश्यकता है। मैं जो बता सकता हूं, वह संबंधपरक डिजाइन सिद्धांतों की व्यापक प्रोग्रामिंग अज्ञानता और एप्लिकेशन के ओओ डिजाइन के एक निर्धारित केंद्रीयता के लिए पैंडर्स की भूमिका निभाता है। लेकिन यह तर्कसंगत पर अपने अस्तित्व का औचित्य नहीं है, अकेले सैद्धांतिक, आधार।

30 वर्षों में डेटाबेस डिज़ाइन में वन ट्रू पाथ नहीं बदला है: डेटा का विश्लेषण करें। कुंजी और बाधाओं और कई-से-एक रिश्तों का पता लगाएं। बॉयस-कोड्ड सामान्य रूप के अनुसार अपनी टेबल डिज़ाइन करें। डेटा एक्सेस की सुविधा के लिए विचारों और संग्रहीत प्रक्रियाओं का उपयोग करें।

हालांकि यह हो सकता है, लेकिन SQL DBMS प्रोग्रामर द्वारा प्रदान की जाने वाली किसी भी चीज़ से बेहतर अलगाव परत प्रदान करता है। यह सच है कि डेटाबेस में परिवर्तन के लिए उपयोग किए जाने वाले SQL को बदलने के लिए इसका उपयोग करना पड़ सकता है। लेकिन ध्यान दें कि एक मध्यस्थता परत है या नहीं, इसकी परवाह किए बिना सच है । जब तक एप्लिकेशन DBMS का उपयोग करने के लिए विचारों और संग्रहीत प्रक्रियाओं का उपयोग करता है, तब तक सामान्य SQL इंजीनियरिंग उपकरण इंगित करेगा जब अंतर्निहित डेटाबेस में परिवर्तन उन विचारों और संग्रहीत प्रक्रियाओं को अमान्य करते हैं।

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

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

उदाहरण के लिए, आप डेटाबेस में कार्य की इकाई को प्रतिबिंबित करने पर विचार करते हैं (तालिका या तालिकाओं के रूप में, मुझे लगता है)। काम की यूनिट : एक अंतर्निहित डीबीएमएस की सेवा है begin transaction... अद्यतन डेटाबेस ... commit transaction। मॉडल के लिए कुछ भी नहीं, SQL में डेटाबेस टेबल के लिए अपनी कक्षाओं के मानचित्रण के अलावा।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.