2010-01-28 21 views
6

मैं सोच रहा था कि निम्नलिखित में से कौन सा मूल बाल संबंधों से निपटने के दौरान सबसे अच्छा अभ्यास माना जाता है।डोमेन संचालित डिजाइन - अभिभावक बाल संबंध पैटर्न - विशिष्टता पैटर्न

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

public class Parent 
{ 
    private ICollection<Child> children; 

    public ReadOnlyCollection Children { get; } 

    public void AddChild(Child child) 
    { 
     child.Parent = this; 
     children.Add(child); 
    } 
} 


public class Child 
{ 
    internal Parent Parent 
    { 
     get; 
     set; 
    } 

    public Child() 
    { 
    } 
} 

2) अगले नमूना देखभाल कि एक बच्चे हमेशा अपने माता-पिता से संबंधित होना चाहिए ले जाएगा के बारे में समस्याओं को यह नेतृत्व नहीं जा सका।

public class Parent 
{ 
    private ICollection<Child> children; 

    public ReadOnlyCollection Children { get; } 

    public Child CreateChild() 
    { 
     var child = new Child(); 
     child.Parent = this; 
     children.Add(child); 
     return child; 
    } 
} 


public class Child 
{ 
    internal Parent Parent 
    { 
     get; 
     set; 
    } 

    internal Child() 
    { 
    } 
} 

3) आखिरी उदाहरण में कि बच्चा अपने माता-पिता के संबंधों का ख्याल रखता है।

public class Parent 
{ 
    private ICollection<Child> children; 

    public ReadOnlyCollection Children { get; } 

    public void AddChild(Child child) 
    { 
     child.Parent = this; 
     children.Add(child); 
    } 
} 


public class Child 
{ 
    public Parent Parent 
    { 
     get; 
     set; 
    } 

    public Child(Parent parent) 
    { 
     this.Parent = parent; 
    } 
} 

कौन सा पैटर्न सबसे अच्छा माना जाता है? मेरा मानना ​​है कि पैटर्न 2 सबसे अच्छा हो सकता है तब से कोई बच्चा अपने माता-पिता के संबंध में कभी अस्तित्व में नहीं हो सकता है। इससे यह आसान हो जाएगा उदा। एक विनिर्देश पैटर्न को कार्यान्वित करते समय:

public class ChildSpecification 
{ 
    bool IsSatisfiedBy(Child child) 
    { 
     return child.Parent.Children.Where(someCondition).Count > 0; 
    } 
} 

उपर्युक्त विनिर्देश केवल तभी काम कर सकता है जब किसी बच्चे के माता-पिता हों।

आपको क्या लगता है? क्या आप बेहतर तरीके जानते हैं? अग्रिम धन्यवाद

उत्तर

0

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

मुझे समझ में नहीं आता आपका विनिर्देश उदाहरण: ऐसा लगता है कि माता-पिता के बच्चों के में कुछ बच्चे के रूप में सत्य होने पर आपके चाइल्डस्पेसिफिकेशन सही हो जाएंगे। निश्चित रूप से असंतुष्ट है (चाइल्ड चाइल्ड) केवल तभी सत्य वापस आना चाहिए जब पैरामीटर के रूप में पारित विशिष्ट बच्चा हालत को संतुष्ट करता है।

+0

विनिर्देश पैटर्न एक विशेष मामले के बारे में है जो वर्तमान में मेरी परियोजनाओं में से एक में है। एक बच्चे की वैधता तिथि सीमा होती है, जिसे बाल संग्रह में किसी भी अन्य बच्चे की किसी अन्य वैधता दिनांक सीमा से अलग नहीं होना चाहिए। क्या आप इसे माता-पिता के लिए एक विनिर्देश मानेंगे? – Chris

+0

मैं इसे माता-पिता की addChild() विधि में एक गार्ड स्थिति के रूप में लागू कर दूंगा। तब माता-पिता जोड़ों को अस्वीकार कर देंगे। अपवाद फेंक कर। मैं शायद इस मामले में एक विनिर्देश का उपयोग नहीं करेंगे। – alasdairg

+0

लेकिन मुझे इसे UI पर भी जांचना होगा। तो जब अपवाद में फेंक दिया जाता है, तो मुझे इसे पकड़ना होगा। यह या तो बहुत सुरुचिपूर्ण नहीं है। और विनिर्देशों के बारे में अच्छी बात यह है कि मैं इसे विभिन्न परिदृश्यों में उपयोग कर सकता हूं जैसे कि 1.) मेरे डोमेन के भीतर 2.) क्लाइंट एप्लिकेशन के भीतर व्यावसायिक तर्क को पूर्व-सत्यापित करने के लिए। या मैं गलत हूँ? – Chris

5

मैं निश्चित रूप से की तरह सुझाव नंबर 2, लेकिन मुझे लगता है कि यह कुछ महत्वपूर्ण है कि 3 में पाया जाता है, अर्थात् है कि यदि एक Child वस्तु एक Parent बिना नहीं हो सकता कि वह अपने निर्माता में एक Parent वस्तु ले जाना चाहिए याद करते हैं। इसके अलावा ParentChild कक्षा पर संपत्ति केवल पढ़ी जानी चाहिए। तो तुम जैसे कुछ के साथ खत्म हो जाएगा:

public class Parent 
{ 
    private ICollection<Child> children; 

    public ReadOnlyCollection Children { get; } 

    public Child CreateChild() 
    { 
     var child = new Child(this); 
     children.Add(child); 
     return child; 
    } 
} 


public class Child 
{ 
    internal Parent Parent 
    { 
     get; 
     private set; 
    } 

    internal Child(Parent parent) 
    { 
     this.Parent = parent; 
    } 
} 
+0

मैं इसे भी ऐसा ही करूंगा, अगर कल्पना यह है कि एक बच्चे को हमेशा माता-पिता होना चाहिए, और उसके माता-पिता को जानने के बिना बनाया नहीं जा सकता है। तो, बस 2 और 3. +1 का संयोजन –

1

के बाद से मैं सिर्फ एक ही डिजाइन desissions और सवाल अब भी चिह्नित नहीं के रूप में जवाब मैं इस समस्या के समाधान पर मेरी दृष्टि पोस्ट करेंगे सामना किया है - शायद यह हूँ किसी की मदद करो। यह समाधान वास्तव में NHibernate के उपयोग के लिए पूरी तरह व्यवहार्य है।

public class Parent 
{ 
    private readonly ISet<Child> _children = new HashedSet<Child>(); 
    public virtual IEnumerable<Child> Children { get { return new ImmutableSet<Child> (this._children); } } 


    protected internal virtual void AddChild (Child child) 
    { 
     this._children.Add(child); 
    } 
} 


public class Child 
{ 
    public virtual Parent Parent { get; protected set; } 


    protected Child() 
    { 
    } 


    public static Create (Parent parent) 
    { 
     if (parent == null) 
      throw new ArgumentNullException ("parent"); 

     var child = new Child 
     { 
      Parent = parent 
     }; 

     child.Parent.AddChild (child); 

     return child; 
    } 
} 

है कि एक तरह से अपने # 2 विकल्प से अलग है कि बच्चे वस्तु (और यह प्रारंभिक मान है अमान्य) के निर्माण पैरेंट ऑब्जेक्ट में भीतर बच्चे को वस्तु ही है और न इकट्ठे हुए हैं के रूप में आप # 2 में सुझाव दिया।

एक बात मुझे यकीन नहीं है कि इसे खराब डिजाइन माना जाता है या नहीं, यदि हम व्यक्तिगत फैक्ट्री विधि (Child.Create) के साथ बाल वस्तुओं को बनाते हैं।

मुझे उम्मीद है कि डीडीडी का उपयोग करने में अधिक अनुभव वाला कोई व्यक्ति उस पर टिप्पणी कर सकता है।

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