डीडीडी - प्रति इकाई रिपोजिटरी या सब कुछ के लिए?

Question

सबसे पहले शायद कोई सही जवाब नहीं है, लेकिन मुझे यकीन है कि ऐसे लोग हैं जो मुझसे ज्यादा जानते हैं और सहायता करने में सक्षम होंगे।

मेरे पास 3 इकाइयां हैं: उपयोगकर्ता, ब्लॉग, पोस्ट।

सिस्टम में कई उपयोगकर्ता हो सकते हैं।

उपयोगकर्ता के पास कई ब्लॉग हो सकते हैं, लेकिन प्रत्येक ब्लॉग में केवल एक उपयोगकर्ता है।

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

फिर मेरे पास उपयोगकर्ता प्रोफाइल पेज है, जहां मैं सभी उपयोगकर्ता विवरण, उनके सभी ब्लॉगों के नाम, और अंतिम 5 पोस्ट प्रदर्शित करना चाहता हूं।

मेरे पास एक ब्लॉग पेज है जो ब्लॉग का विवरण, मालिक का नाम (उपयोगकर्ता) और सभी पदों के शीर्षक प्रदर्शित करता है।

तब मेरे पास पोस्ट पेज है जो पोस्ट विवरण, ब्लॉग नाम और मालिक का नाम प्रदर्शित करता है।

जैसा कि आप देखते हैं कि मेरे पास उनके बीच संबंध हैं, लेकिन उनमें से कोई भी कुल के रूप में कार्य नहीं कर सकता है।

कोड में इकाइयों को परिभाषित करना मुश्किल नहीं है, मेरे पास क्या समस्याएं हैं जो भंडार को परिभाषित कर रही हैं। मुझे कितनी आवश्यकता है? 3 - प्रत्येक इकाई प्रति एक? 1 - सब कुछ के लिए? मैं लुक-अप कैसे करूं?

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

अग्रिम धन्यवाद।

Answer 1

मैं बनाना होगा:

• एक PostRepository पदों को संभालने के लिए इस्तेमाल किया और टिप्पणी
• BlogRepository खोज
• UserRepository

आप टिप्पणी मैं करूंगा समर्थन करने के लिए नहीं जा रहे हैं के लिए ज्यादातर इस्तेमाल किया पोस्ट रिपॉजिटरी को हटाएं और BlogRepository

में पदों को संभालें

मैं आम तौर पर उनके उपयोग के बाद भंडार मॉडल करता हूं और योगों के घोंसले से बचने के लिए (दो से अधिक स्तर)।

उदाहरण के लिए उपयोगकर्ता पेज में 5 अंतिम पोस्ट प्राप्त करने के लिए। उपयोगकर्ता के पास ब्लॉग का कंटेनर रखने के बजाय पदों का संदर्भ नहीं है, जहां प्रत्येक ब्लॉग में बदले में पोस्ट के कंटेनर होते हैं।

imho उपयोगकर्ता को Blog पर कंटेनर नहीं होना चाहिए। आपके पास इसे लाने के लिए भंडार है।

क्या मेरे पास मेरे भंडार में एक विधि होनी चाहिए जो उपयोगकर्ता आईडी स्वीकार करता है और पदों की एक सूची देता है?

हाँ।

या शायद यह एक सेवा होनी चाहिए?

सेवा का उपयोग डोमेन मॉडल का उपयोग करने वाले कोड से व्यावसायिक तर्क को हटाने के लिए किया जाता है। उन्हें तब तक न बनाएं जब तक आप उस तरह के तर्क प्राप्त न करें।

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

आलसी लोडिंग को उन सभी गुणों से बचा जा सकता है जो सभी डोमेन मॉडल को एक साथ जोड़ते हैं। केवल बच्चे समेकन के गुणों का प्रयास करें।

Answer 2

उपयोगकर्ता अक्सर एक सामान्य समग्र रूट होता है। उपयोगकर्ता कुल में उपयोगकर्ता प्राथमिकताएं, उपयोगकर्ता आंकड़े, यहां तक ​​कि ब्लॉग भी हो सकते हैं।

मैं एक समग्र रूट के लिए एक अच्छी उम्मीदवार के रूप में पोस्ट को देखता हूं जिसमें बहुत सी चीजें इसके चारों ओर गुरुत्वाकर्षण करती हैं: टिप्पणियां, टैग, श्रेणियां ... फिर आप PostRepository.LoadByBlog() या PostRepository.LoadByUser() का उपयोग कर सकते हैं पृष्ठों की है।

अब यह आपके द्वारा वर्णित एक से केवल एक संभावना है। प्रत्येक डोमेन अद्वितीय है और आपके पास गेम बदलने वाली जानकारी हो सकती है जिसे हम नहीं जानते हैं।

Answer 3

मैं यह तय करने से पहले कि आपके पास भंडार होगा या नहीं, मैं आपकी इकाई का महत्व देखूंगा।

परीक्षण संचालित विकास पक्ष से देखकर, मेरे पास प्रत्येक इकाई के लिए एक भंडार होगा। इस तरह से IUserRepository, IBlogPostRepository इत्यादि का नकली कार्यान्वयन हो सकता है। यह दृष्टिकोण इकाई परीक्षण को बढ़ावा देता है और मुझे दूसरे के साथ भंडार के एक कार्यान्वयन को प्रतिस्थापित करने की अनुमति देता है।

तब मैं अपने भंडारों को सेवाओं में समूहित करता हूं क्योंकि मैं उपयुक्त महसूस करता हूं। ऐसा करने का एक तरीका, उपयोग मामलों और समूह को इस तरह से लिखना है कि आपकी आवश्यकताओं के अनुरूप हो।

उदाहरण के लिए, मैं कह सकता हूँ कि एक उपयोगकर्ता कर सकते हैं निम्नलिखित:

1. पोस्ट देखें
2. जमा करें पोस्ट
3. पोस्ट संपादित करें

मैं अब देखने के लिए एक IUserService कर सकते हैं , पदों को सबमिट और संपादित करना। यह सेवा मेरे भंडारों को एकत्रित करेगी (समूह)।

अंत में, मैं निम्नलिखित ऐसा करने में सक्षम हो जाएगा।

var blogPost = new BlogPost(); 
ServiceFactory.Resolve<IUserService>(c => c.SubmitPost(blogPost)); 

अब, यह करने का यह एक तरीका है।

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

प्वाइंट है कि मैं "बनाने की कोशिश कर हूँ, कि आप छोटे विवरण पर लटका नहीं करना चाहिए। समान व्यवहार को प्राप्त करने का सामान्य रूप से कई तरीके हैं, और एक ही तरीका है कि आप सीखना होगा अभ्यास द्वारा है।

मेक आपके भंडार पुनः उपयोग करने योग्य हैं, लेकिन खुद से पूछें कि क्या आप कुछ इंजीनियरिंग कर रहे हैं, यानी मैं कभी भी इस भंडार का उपयोग करने जा रहा हूं? एक बार जब आप कुछ भंडार प्राप्त कर लेते हैं, तो उन्हें कुल सेवा में लपेटें।

यदि आपके पास सेवा है अधिक तो 3 खजाने (सीमा के आप निर्भर करता है), तो दो अलग-अलग सेवाओं में इस सेवा पुनर्रचना पर विचार करें।

मुझे आशा है कि इससे मदद मिलती है।