मैंने अभी DDD पढ़ना शुरू किया है। मैं पूरी तरह से मूल्य बनाम वस्तुओं की अवधारणा को समझ पाने में असमर्थ हूं .. क्या कोई कृपया समस्याओं (रखरखाव, प्रदर्शन आदि) की व्याख्या कर सकता है जब एक मूल्य वस्तु को इकाई वस्तु के रूप में डिज़ाइन किया गया है, एक प्रणाली सामना कर सकती है? उदाहरण बहुत अच्छा होगा ...
जवाबों:
आवश्यक अंतर के लिए कम, संस्थाओं के लिए पहचान मायने रखती है, लेकिन मूल्य वस्तुओं के लिए कोई फर्क नहीं पड़ता। उदाहरण के लिए, किसी का नाम एक मूल्य वस्तु है। एक ग्राहक इकाई एक ग्राहक नाम (मान ऑब्जेक्ट), सूची <आदेश> ऑर्डरहिस्ट्री (संस्थाओं की सूची), और शायद एक डिफ़ॉल्ट पते (आमतौर पर एक मूल्य वस्तु) से बना हो सकती है। ग्राहक इकाई में एक आईडी होगी, और प्रत्येक आदेश में एक आईडी होगी, लेकिन एक नाम नहीं होना चाहिए; आम तौर पर, वैसे भी ऑब्जेक्ट मॉडल के भीतर, एक पते की पहचान शायद मायने नहीं रखती है।
मूल्य वस्तुओं को आमतौर पर अपरिवर्तनीय वस्तुओं के रूप में दर्शाया जा सकता है; मूल्य ऑब्जेक्ट की एक संपत्ति को बदलना अनिवार्य रूप से पुरानी वस्तु को नष्ट कर देता है और एक नया बनाता है, क्योंकि आप सामग्री के साथ पहचान के साथ संबंधित नहीं हैं। उचित रूप से, नाम पर समान उदाहरण विधि "सत्य" लौटाएगी जब तक कि वस्तु के गुण दूसरे उदाहरण के गुणों के समान हों।
हालाँकि, ग्राहक जैसी किसी इकाई की कुछ विशेषता को बदलने से ग्राहक नष्ट नहीं होता है; एक ग्राहक इकाई आमतौर पर परिवर्तनशील होती है। पहचान वही रहती है (कम से कम एक बार वस्तु बनी रहने के बाद)।
आप शायद इसे साकार करने के बिना मूल्य वस्तुओं का निर्माण करते हैं; जब भी आप एक महीन दाने वाली कक्षा बनाकर किसी इकाई के कुछ पहलू का प्रतिनिधित्व कर रहे हैं, तो आपको एक मूल्य वस्तु मिल गई है। उदाहरण के लिए, एक वर्ग IPAddress, जिसके पास वैध मूल्यों पर कुछ अड़चनें हैं, लेकिन सरल डेटाटिप्स से बना है, एक मूल्य वस्तु होगी। एक EmailAddress एक स्ट्रिंग हो सकता है, या यह व्यवहार के अपने सेट के साथ एक मूल्य वस्तु हो सकता है।
यह बहुत संभव है कि आपके डेटाबेस में जिन वस्तुओं की पहचान है, उनमें भी आपके ऑब्जेक्ट मॉडल में कोई पहचान न हो। लेकिन सबसे सरल मामला कुछ विशेषताओं का एक संयोजन है जो एक साथ समझ में आता है। आप शायद ग्राहक नहीं चाहते। जब तक आप दृढ़ता के बारे में सोचते हैं, तब तक वे संभवतः आपके डेटाबेस में कई फ़ील्ड होंगे, लेकिन आपका ऑब्जेक्ट मॉडल परवाह नहीं करता है।
int[1]हो सकता है कि एक साझा किए गए परिवर्तनशील मूल्य, एक साझा करने योग्य अपरिवर्तनीय मूल्य (यदि कोई भी चीज़ जो संदर्भों को कभी भी लिखेगी, तो वह लिखेगा), या एक इकाई (यदि दो या अधिक संदर्भ मौजूद हैं, और उनमें से एक को लिखने के लिए उपयोग किया जा सकता है। मान जो दूसरे का उपयोग करके पढ़ा जा सकता है)। दुर्भाग्यवश, मुझे जावा या .NET में उन क्लास ऑब्जेक्ट्स को रोकने के लिए कोई भाषा समर्थन नहीं है जो उत्परिवर्ती मूल्यों को संस्थाओं में बदलने से रोकते हैं।
कोई भी वस्तु जो कि सभी के गुणों द्वारा सामूहिक रूप से परिभाषित की जाती है, एक मूल्य वस्तु है। यदि कोई विशेषता बदल जाती है तो आपके पास मान ऑब्जेक्ट का एक नया उदाहरण है। यही कारण है कि मूल्य वस्तुओं को अपरिवर्तनीय के रूप में परिभाषित किया गया है।
यदि वस्तु को उसके सभी गुणों द्वारा पूरी तरह से परिभाषित नहीं किया गया है, तो विशेषताओं का एक सबसेट है जो वस्तु की पहचान बनाते हैं। शेष विशेषताओं को वस्तु को फिर से परिभाषित किए बिना बदल सकते हैं। इस तरह की वस्तु को अपरिवर्तनीय रूप से परिभाषित नहीं किया जा सकता है।
अंतर बनाने का एक सरल तरीका मूल्य वस्तुओं को स्थिर डेटा के रूप में सोचना है जो आपके अनुप्रयोग में विकसित होने वाले डेटा के रूप में कभी नहीं बदलेगा और निकालेगा।
मूल्य प्रकार:
संस्थाओं:
मुझे नहीं पता कि निम्नलिखित सही है या नहीं, लेकिन मैं कहूंगा कि एक एड्रेस ऑब्जेक्ट के मामले में, हम एक एंटिटी के बजाय एक वैल्यू ऑब्जेक्ट के रूप में इसका उपयोग करना चाहते हैं, क्योंकि इकाई में परिवर्तन सभी लिंक की गई वस्तुओं पर प्रतिबिंबित होगा ( उदाहरण के लिए एक व्यक्ति)।
इस मामले को लें: आप कुछ अन्य लोगों के साथ अपने घर में रह रहे हैं। यदि हम पते के लिए इकाई का उपयोग करेंगे, तो मैं तर्क दूंगा कि एक अद्वितीय पता होगा जो सभी व्यक्ति वस्तुओं से लिंक करता है। यदि कोई व्यक्ति बाहर जाता है, तो आप उसका पता अपडेट करना चाहते हैं। यदि आप एड्रेस एंटिटी के गुणों को अपडेट करेंगे, तो सभी लोगों के पास एक अलग पता होगा। मान ऑब्जेक्ट के मामले में, हम पते को संपादित नहीं कर पाएंगे (क्योंकि यह अपरिवर्तनीय है) और हम उस व्यक्ति के लिए एक नया पता प्रदान करने के लिए मजबूर होंगे।
क्या यह सही लगता है? मुझे कहना होगा कि मैं डीडीडी पुस्तक पढ़ने के बाद भी इस अंतर को लेकर उलझन में था।
एक कदम आगे बढ़ते हुए, यह कैसे डेटाबेस में प्रतिरूपित होगा? क्या आपके पास व्यक्तिगत तालिका में स्तंभ के रूप में पता ऑब्जेक्ट के सभी गुण होंगे या आप एक अलग पता तालिका बनाएंगे जिसमें एक विशिष्ट पहचानकर्ता भी होगा? बाद के मामले में, एक ही घर में रहने वाले लोगों के पास प्रत्येक एक पते की वस्तु का एक अलग उदाहरण होगा, लेकिन उन वस्तुओं को उनकी आईडी संपत्ति को छोड़कर समान होगा।
मैंने इसके बारे में एक और सूत्र में पूछा और मुझे लगता है कि मैं अभी भी भ्रमित हूं। मैं डेटा मॉडलिंग के साथ प्रदर्शन के विचारों को भ्रमित कर सकता हूं। हमारे कैटलॉगिंग एप्लिकेशन में, ग्राहक को तब तक नहीं बदलता जब तक कि उसे इसकी आवश्यकता न हो। यह गूंगा लगता है - लेकिन ग्राहक डेटा का 'रीड' दूर तक लिखता है और चूंकि कई वेब अनुरोध सभी वस्तुओं के 'सक्रिय सेट' पर हैं, इसलिए मैं ग्राहकों को बार-बार लोड नहीं करना चाहता। इसलिए मुझे ग्राहक ऑब्जेक्ट के लिए एक अपरिवर्तनीय सड़क के नीचे रखा गया था - इसे लोड करें, इसे कैश करें, और ग्राहक को देखना चाहते हैं (मल्टी थ्रेडेड) अनुरोधों के 99% तक एक ही सेवा करें। फिर, जब कोई ग्राहक कुछ बदलता है, तो एक नया ग्राहक बनाने और पुराने को अमान्य करने के लिए एक 'संपादक' प्राप्त करें।
मेरी चिंता यह है कि यदि कई थ्रेड्स में एक ही ग्राहक ऑब्जेक्ट दिखाई देता है और यह परिवर्तनशील है, तो जब एक धागा बदलना शुरू होता है तो अन्य में तबाही हो सकती है।
मेरी समस्याएं अब 1 हैं, यह उचित है, और 2) गुणों के बारे में बहुत सारे कोड को दोहराए बिना यह कैसे करना सबसे अच्छा है।
के बीच 3 अंतर EntitiesऔरValue Objects
आइडेंटिफ़ायर बनाम स्ट्रक्चरल इक्वैलिटी: एंटिटीज़ में आइडेंटिफ़ायर होता है, अगर आइडेंटिफ़ायर एक जैसा होता है। हाथ से परे मूल्य वस्तुओं में संरचनात्मक समानता होती है, हम दो मूल्य वस्तुओं को समान मानते हैं जब सभी क्षेत्र समान होते हैं। मान ऑब्जेक्ट में पहचानकर्ता नहीं हो सकता है।
म्यूटेबिलिटी बनाम अपरिवर्तनीयता: मूल्य वस्तुएँ अपरिवर्तनीय डेटा संरचनाएं हैं, जबकि इकाइयाँ उनके जीवन काल के दौरान बदलती रहती हैं।
जीवन काल: मूल्य वस्तुओं का संबंध संस्थाओं से होना चाहिए
एक बहुत ही सरल वाक्य में, मैं कह सकता हूं कि हमारे पास तीन प्रकार की समानताएं हैं:
आइडेंटिफ़ायर समानता केवल एंटिटी को संदर्भित करता है और संरचनात्मक समानता केवल वैल्यू ऑब्जेक्ट को संदर्भित करता है। वास्तव में वैल्यू ऑब्जेक्ट्स में आईडी नहीं होती है और हम इनका इस्तेमाल परस्पर कर सकते हैं। यह भी मान वस्तुओं अपरिवर्तनीय होना चाहिए और संस्थाओं को परिवर्तित किया जा सकता है और मूल्य वस्तुओं डेटाबेस में नाय टेबल नहीं होगा।