डीडीडी इकाइयों को संदर्भ या आईडी द्वारा तुलना की जानी चाहिए?

Question

जब मैंने डीडीडी का उपयोग करना शुरू किया, तो मैंने इकाई की आईडी की तुलना में मेरी इकाइयों में Equals() विधियां बनाईं। तो एक ही आईडी के साथ दो इकाई वस्तुओं बराबर माना जाएगा।

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

मैं तो मार्क सीनैन, जहां उसने लिखा है, तो उनकी आईडी एक दूसरे के बराबर

संस्थाओं के बराबर हैं द्वारा this answer से अधिक ठोकर खाई।

अब, मैं जानना चाहता हूं कि कौन सा दृष्टिकोण बेहतर है।

संपादित करें: ध्यान दें कि प्रश्न नहीं है कि एक ही समय में एक ही इकाई के दो उदाहरण एक अच्छा विचार है। मुझे पता है कि ज्यादातर स्थितियों में शायद यह नहीं है।

Answer 1

प्रश्न दो गुना है। सबसे पहले, आप वास्तव में क्या जानना चाहते हैं

जब मैं एक डोमेन मॉडल कोड करता हूं तो एक्स भाषा (या वाई फ्रेमवर्क) लागू होने वाली शर्तों को कैसे संभाला जाए?

सी # उदाहरण के लिए आपको लगाता है कि आपके द्वारा परिभाषित कोई भी नई अवधारणा certain set of public methods प्राप्त करती है। जावा में even more methods शामिल है।

मैंने कभी भी हैश कोड या इंस्टेंस समानता के बारे में बात करने वाले एक डोमेन विशेषज्ञ को नहीं सुना है, लेकिन यह उन स्थितियों में से एक है जब इवान्स से "ढांचे से लड़ना नहीं है" उद्धरण लागू होता है: बस डेवलपर्स को सिखाएं उनका उपयोग न करें जब वे डोमेन के इंटरफेस से संबंधित न हों।

फिर, क्या आप जानना चाहते हैं

एक इकाई क्या है? यह अपनी पहचान से कैसे संबंधित है?

क्यों शुरू करें! आप जानते हैं कि संस्थाएं सर्वव्यापी भाषा की शर्तों हैं जो पहचाने जाने योग्य हैं।

लेकिन क्यों?

सादा सरल: संस्थाओं अवधारणाओं जिसका समय में विकास संदर्भ समस्या हम हल करते है की में प्रासंगिक है वर्णन!

यह प्रासंगिकता है जो कि इकाई को परिभाषित करता है, न कि दूसरी तरफ! पहचान इसके बारे में बात करने के लिए, विकास का ट्रैक रखने के लिए सिर्फ एक संचार उपकरण है।

उदाहरण के तौर पर आपके बारे में सोचें: आप एक नाम वाले व्यक्ति हैं; हम आपके जीवन के दौरान शेष दुनिया के साथ आपकी बातचीत के बारे में संवाद करने के लिए आपके नाम का उपयोग करते हैं; फिर भी, आप वह नाम नहीं हैं।

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

Answer 2

मुझे लगता है कि अलग-अलग राज्यों में एक ही इकाई के दो अलग-अलग उदाहरण होने का बुरा विचार है। मैं ऐसे परिदृश्य के बारे में नहीं सोच सकता जहां वह वांछनीय होगा। शायद एक है? मेरा मानना ​​है कि किसी विशेष आईडी के साथ किसी दिए गए इकाई का केवल एक उदाहरण होना चाहिए।

आम तौर पर मैं उनकी आईडी का उपयोग करके उनकी समानता की तुलना करता हूं।

लेकिन अगर आप अगर वे एक ही वस्तु संदर्भ हैं जाँच करना चाहते थे तो आप इस्तेमाल कर सकते हैं:

 if (Object.ReferenceEquals(entityA, entityB)) 
     { 
      DoSomething(); 
     } 

Answer 3

संस्थाओं पहली जगह में, इस तरह की तुलना नहीं की जानी चाहिए। कोई मान्य उपयोग केस नहीं है (परीक्षण के बाहर, लेकिन फिर फिर से दावा पुस्तकालय को आपके लिए इसे संभालना चाहिए) यह देखने के लिए कि क्या 2 इकाइयां ऑब्जेक्ट के बराबर विधि का उपयोग कर बराबर हैं या नहीं।

क्या एक इकाई अद्वितीय है जो आईडी है। आईडी का उद्देश्य यह कहना है कि 'समान गुण/मूल्यों के बावजूद यह इकाई अन्य संस्थाओं से अलग है।'

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

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

डीडीडी करते समय, प्रोग्रामर (यानी तकनीकी पहलुओं) की तरह नहीं सोचें एक वास्तुकार (उच्च स्तर) की तरह सोचें। कोड, प्रोग्रामिंग भाषा आदि सिर्फ एक कार्यान्वयन विस्तार है।