2013-08-07 3 views
11

सबसे पहले मैं यह स्पष्ट करना चाहता हूं कि मैं डोमेन संचालित डिजाइन में नया हूं और मैं इस सवाल से पूछ रहा हूं क्योंकि मैंने एनीमिक डोमेन मॉडल नामक कुछ पढ़ी है।डोमेन संचालित डिजाइन के साथ रिपोजिटरी पैटर्न विरोधी पैटर्न बन गया है?

रिपोजिटरी पैटर्न के साथ काम करते समय अधिकांश समय मैं निम्नलिखित चीज़ों को देखता हूं।

  1. हम एक सामान्य भंडार
  2. हम मॉडल है कि केवल सार्वजनिक संपत्तियों की सेट होते हैं, लेकिन यह किसी भी तरीके से शामिल नहीं है (तो यह DDD की परिभाषा के अनुसार खून की कमी डोमेन मॉडल हो जाते हैं) क्योंकि यहाँ भंडार वर्ग अन्य संभाल है उस इकाई या मॉडल के लिए प्रक्रिया।

कृपया मेरी क्वेरी के लिए अपना मूल्यवान उत्तर प्रदान करें।

मुझे कुछ चीजों को स्पष्ट करने दें।

जेनेरिक रिपोजिटरी का अर्थ जेनेरिक इंटरफ़ेस है जो एंटीटी रिपोजिटरी द्वारा कार्यान्वित किया जाता है।

मेरे भ्रम बात

उदाहरण के लिए निम्नलिखित के संबंध में है: मान लीजिए मैं

public class User 
    { 
     public int Id { get; set;} 
     public string Name { get; set}; 
    } 

    public class UserRepository : IRepository<User> 
    { 
     // All Operation Like Save/Get/UserEntity (Domain Object)  
    } 

तो यहाँ के बजाय यह सिर्फ UserRespository से गुण और अन्य संचालन संभाल रहा है मेरी उपयोगकर्ता वर्ग कुछ नहीं कर सहेजना चाहते हैं। तो मेरा उपयोगकर्ता एनीमिक डोमेन मॉडल है। (जैसा कि यह कुछ भी विशिष्ट नहीं है)

यहां संलग्न छवि में मैं ProductRepository पर विचार करता हूं इसलिए मेरा प्रश्न है: क्या मेरा उत्पाद वर्ग एक एनीमिक मॉडल है?

कृपया जो मैं कहने की कोशिश कर रहा हूं उसके लिए नमूना छवि का पालन करने पर विचार करें।

enter image description here

+0

क्या आप और विस्तार कर सकते हैं? क्या आपको लगता है कि रिपोजिटरी एक एंटीपाटरन होगा? किसी की राय? अपनी खुद की? प्रश्न में कुछ मूल्य रखो अगर आप मूल्यवान उत्तरों :) –

+0

उम्मीद यह मेरी अपनी नहीं है कि भंडार विरोधी पैटर्न है, लेकिन मैं जिस तरह से खून की कमी डोमेन मॉडल परिभाषा और भंडार पैटर्न को भ्रमित कर रहा हूँ। भंडार पैटर्न की तरह की इकाई लेकिन संस्था की सेव खुद को बचाने के लिए कोई भी तरीका नहीं है ध्यान रखना। – dotnetstep

+0

यह डीडीडी में पूरी तरह से मान्य होगा, सेवाओं के रूप में भंडारों के बारे में सोचें। https://groups.google.com/d/msg/dddcqrs/krOf_dqnD8o/qpTc0OPQSMQJ –

उत्तर

15

भंडार पैटर्न एक विरोधी पैटर्न नहीं है दर असल, लेकिन मैं DDD के कई प्रयोगों जहां भंडार पैटर्न और कोई काम नहीं प्रदान की अब तक देखा है। अपने एन-टियर-प्रदान-नो-वैल्यू स्तरित आर्किटेक्चर को व्यावहारिक कट्टर विशेषज्ञ देव को सौंपें और वह शायद आपको "एंटी-पैटर्न" आलोचना (और वैध मैं कह सकता हूं) दे दूंगा।

भंडार पैटर्न पेशेवरों:

  1. अंतर्निहित हठ प्रौद्योगिकी
  2. अपनी समेकित जड़ों को परिभाषित करने के लिए एक संभावना का एक अमूर्त, केवल कुल जड़ों खजाने
  3. स्पष्ट रूप से बताते हुए का एक तरीका है जो संचालन मान्य हैं होना चाहिए प्रश्न में कुल रूट के लिए, उदाहरण के लिए यदि यह आपकी इकाई को हटाने के लिए मान्य नहीं है, तो आपके भंडार में कोई डिलीट विधि नहीं होनी चाहिए।
  4. कुछ एक डेटाबेस के बिना परीक्षण करने के लिए आसान है कि

भंडार पैटर्न विपक्ष (अपने खजाने छोटा करते): अपने हठ प्रौद्योगिकी के लिए

  1. निकटता।
  2. यात एक और टियर

व्यक्तिगत तौर पर मैं जब DDD कर भंडार पद्धति का उपयोग कर पसंद करते हैं, लेकिन अपने समाधान अधिक सक्रिय रिकॉर्ड पैटर्न की तरह लगता है, इस प्रकार पहली जगह में खजाने के उपयोग के लाभ के सबसे को हटाने। मैं सामान्य भंडार कभी नहीं करता क्योंकि वे पेशेवर 2 & 3 हटाते हैं (मैं एक सामान्य कार्यान्वयन कर सकता हूं, लेकिन मैं इसे सीधे भंडार-उपभोक्ता कोड पर बेनकाब नहीं करता)।

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

20

मैं मानता हूं कि IRepository इंटरफ़ेस आम तौर पर समय की बर्बादी है। यदि मैंने अपने IRepository इंटरफ़ेस में मूल CRUD संचालन किया है, तो मैं ऑडिट डेटा जैसे डेटा से कैसे निपटूं? इसे हटाने पर वर्जित किया जाएगा। जब मैं Delete() पर कॉल करने का प्रयास करता हूं तो क्या मुझे बस InvalidOperationException वापस करना चाहिए?

कुछ लोगों IReadable, IWriteable, IUpdateable या IDeleteable जैसे छोटे इंटरफेस का सुझाव दिया है। मुझे लगता है कि यह दृष्टिकोण भी गड़बड़ है।

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

भंडार पैटर्न के लिए और उसके खिलाफ ऑनलाइन कई तर्क हैं।

संबंधित मुद्दे