2012-02-24 14 views
5

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

संस्थाओं के बारे में धारा:

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

http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

+0

संभावित डुप्लिकेट, देख http://stackoverflow.com/questions/5031614/the-jpa-hashcode-equals-dilemma – MRalwasser

+0

आईडी मेरे लिए ठीक काम करता है: http://stackoverflow.com/questions/7579404/उपयोग-ऑटो-जेनरेट-आईडी-ऑफ-हाइबनेट-इकाई-ऑब्जेक्ट-इन-द-बराल्स-एंड-हैशकोड-मिले – NimChimpsky

उत्तर

1

युगल संभव दृष्टिकोण:

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

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

  • इकाई वर्गों के लिए डिफ़ॉल्ट equals() पर भरोसा करने का विकल्प भी है।यह दो मेमोरी स्थानों की तुलना करेगा और यह ज्यादातर मामलों में पर्याप्त है क्योंकि Unit Of Work (हाइबरनेट सत्र) सभी इकाइयों को रखता है (इस ओआरएम पैटर्न को Identity Map कहा जाता है)। यह विश्वसनीय नहीं है अगर आप संस्थाओं है कि एक हाइबरनेट सत्र के दायरे तक सीमित नहीं हैं (थिंक सूत्र, अलग संस्थाओं आदि)

दिलचस्प बात यह 'सरकारी' DDD नमूना का उपयोग करता है एक बहुत ही उपयोग करें, क्योंकि यह टूट जाएगा हल्के ढांचे जहां हर इकाई वर्ग एक विधि के साथ Entity इंटरफ़ेस से प्राप्त होता है: गुण name, surname साथ

boolean sameIdentityAs(T other) 
// Entities compare by identity, not by attributes. 
+0

मान लें कि इकाई प्रश्न थी। मैं क्या उपयोग करूंगा? मैंने अब तक जेनरेट आईडी पर भरोसा किया है। – LuckyLuke

+0

आपके डोमेन पर निर्भर करता है, शायद प्रश्न का टेक्स्ट (जिस स्थिति में यह शायद मूल्य नहीं है), लेकिन अधिक संभावना प्रश्न संख्या की तरह कुछ। वास्तव में आपके डोमेन पर निर्भर करता है। – Dmitry

1

वस्तु स्थायी नहीं होती है अभी तक, तो उनकी विशेषताओं के आधार पर 2 वस्तुओं की तुलना में किसी भी नुकसान है?

मुझे यकीन नहीं है कि यह आपकी परियोजना में क्यों विफल रहा है, लेकिन मेरे अनुभव में, गुणों के आधार पर तुलना लगभग हमेशा फिसलन ढलान है यदि आपके गुण अंतिम नहीं हैं। इसका मतलब है कि, 2 ऑब्जेक्ट्स जो बराबर हैं, कुछ समय के बाद बराबर नहीं हो सकते हैं। यह बहुत बुरा है।

यह देखते हुए कि अधिकांश जावा कक्षाएं उनके एक्सेसर्स के साथ लिखी जाती हैं, गुणों की तुलना करने के बराबर एक बुरा विचार माना जाता है।

हालांकि, मैं शायद यह देखने के लिए जांच करता हूं कि आईडी फ़ील्ड शून्य नहीं है या नहीं। यदि यह शून्य है, तो मैं विशेषता तुलना में वापस आऊंगा। यदि यह शून्य नहीं है, तो बस इसका इस्तेमाल करें और कुछ और नहीं करें। इसका कोई मतलब भी है क्या?

+2

यह करना एक खतरनाक बात है। यदि आप अपनी आईडी निर्दिष्ट करने से पहले ऑब्जेक्ट को हैशसेट में संग्रहीत करते हैं, तो हैशसेट दूषित हो जाएगा। निश्चित रूप से –

+0

। लेकिन, फिर, मुझे लगता है कि आप आईडी प्राप्त करने के लिए ऑब्जेक्ट को बनाए रखेंगे। इस मामले में, मैं आमतौर पर लगातार ऑब्जेक्ट प्राप्त करना पसंद करता हूं जो वापस लौटाया जाता है और इसका उपयोग करता है। असल में, ऑब्जेक्ट की स्थिति को म्यूटेट न करें जो समानता जांच में उपयोग किया जाता है। – Pavan

+0

यदि आप इसके गुणों के आधार पर वस्तुओं की तुलना करते हैं तो यह एक मूल्य वस्तु के रूप में व्यवहार नहीं कर रहा है। मूल्य वस्तुओं और संस्थाओं में डीडीडी में काफी अलग अर्थशास्त्र हैं इसलिए आपको गुणों पर इकाई समानता का आधार नहीं होना चाहिए। –

1

को देखते हुए Person वर्ग। जब 21 साल की उम्र में व्यक्ति अपना नाम बदलता है तो यह अभी भी वही व्यक्ति है (बराबर true देता है)? यदि आप गुणों के आधार पर बराबर लिखते हैं, तो, यह वही व्यक्ति नहीं होगा, इसलिए मेरी राय में सबसे अच्छा तरीका है कि वे अपने व्यावसायिक पहचानकर्ता (संपूर्ण इकाई जीवन चक्र पर अद्वितीय और अपरिवर्तनीय) पर संस्थाओं के समानता का परीक्षण करें।

0

एक अन्य समाधान आपकी इकाई में UUID फ़ील्ड का उपयोग करने के लिए किया जा सकता है।

इस मामले में, आप UUID प्राथमिक कुंजी या केवल बराबर के लिए उपयोग कर सकते हैं।

@Entity 
public class YourEntity{ 

    @Id 
    private String uuid = UUID.randomUUID().toString(); 

    // getter only... 

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