डीडीडी में डेटा एक्सेस?

Question

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

Answer 1

CRUD-ish विधियों को रिपोजिटरी का हिस्सा होना चाहिए ... ish। लेकिन मुझे लगता है कि आपको पूछना चाहिए कि आपके पास सीआरयूडी विधियों का समूह क्यों है। वे वास्तव में क्या करते हैं? वे वास्तव में के लिए क्या हैं? यदि आप वास्तव में डेटा एक्सेस पैटर्न को कॉल करते हैं तो आपका एप्लिकेशन उपयोग करता है, मुझे लगता है कि यह भंडार को और अधिक उपयोगी बनाता है और आपको अपने डोमेन के कुछ प्रकार के परिवर्तन होने पर शॉटगन सर्जरी करने से रोकता है।

CustomerRepo.GetThoseWhoHaventPaidTheirBill() 

// or 

GetCustomer(new HaventPaidBillSpecification()) 

// is better than 

foreach (var customer in GetCustomer()) { 
    /* logic leaking all over the floor */ 
} 

"सहेजें" प्रकार विधियों को भी भंडार का हिस्सा होना चाहिए।

यदि आपके पास कुल जड़ों हैं, तो यह आपको रिपोजिटरी विस्फोट होने से रोकता है, या तर्क खत्म हो जाता है: आपके पास डेटा एक्स एक्सेस पैटर्न के 4 x # नहीं हैं, केवल वही जो आप वास्तव में कुल पर उपयोग करते हैं जड़ों।

यह मेरा $ .02 है।

Answer 2

यहां तक ​​कि एक डीडीडी में, मैं डेटा एक्सेस कक्षाओं और दिनचर्या से अलग दिनचर्या रखता हूं।

कारण हैं,

1. Testability, बेहतर बनाता है चिंताओं के
2. पृथक्करण और मॉड्यूलर डिज़ाइन
3. अधिक लंबे समय में पोषणीय के रूप में आप संस्थाओं को जोड़ने, दिनचर्या

मैं कोई विशेषज्ञ हूँ , एकदम मेरे विचार।

Answer 3

निल्सन के आवेदन डीडीडी & पी के साथ कष्टप्रद बात यह है कि वह हमेशा "मैं वास्तविक दुनिया में आवेदन नहीं करता लेकिन ..." और फिर उसका उदाहरण निम्नानुसार चलता है। विषय पर वापस जाएँ: मुझे लगता है कि ऑर्डर रेपॉजिटरी.गेटऑर्डरर्स बाय कस्टमर (ग्राहक) जाने का रास्ता है, लेकिन डीडीडी के बारे में ALT.Net मेलिंग सूची (http://tech.groups.yahoo.com/group/altdotnet/) पर भी एक चर्चा है।

Answer 4

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

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

एक चीज सावधान रहना है कि यह तरीका है कि भंडार से पीड़ित हो सकता है। GetOrderbyCustomer .. GetAllOrders .. GetOrders30Daysld .. आदि। इस समस्या का एक अच्छा समाधान क्वेरी ऑब्जेक्ट पैटर्न को देखना है। और फिर आपके भंडार निष्पादित करने के लिए केवल एक क्वेरी ऑब्जेक्ट ले सकते हैं।

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

Answer 5

डीडीडी आम तौर पर ग्राहक के साथ संकेतित सक्रिय रिकॉर्ड पैटर्न पर रिपोजिटरी पैटर्न पसंद करता है। सहेजें।

सक्रिय रिकॉर्ड मॉडल में एक नकारात्मक पक्ष यह है कि यह कुछ विशेष रूप से घुसपैठ कोड (अधिकांश भाषाओं में) को छोड़कर, एक एकल दृढ़ता मॉडल मानता है।

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

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

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

Answer 6

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

customer.Orders; 

तो अपने प्रश्न का उत्तर देने के लिए, सीआरयूडी परिचालन कुल रूट भंडारों पर मौजूद हैं।

CustomerRepository.Add(customer); 
CustomerRepository.Get(customerID); 
CustomerRepository.Save(customer); 
CustomerRepository.Delete(customer);