डोमेन में निरंतरता एनोटेशन एक बुरी आदत है?

Question

मुझे एहसास है कि मॉर्फिया और हाइबरनेट जैसे दृढ़ता ढांचे डोमेन ऑब्जेक्ट्स पर अपने जादू करने के लिए एनोटेशन पर भरोसा करते हैं। कुछ स्तर पर, मुझे ऐसा लगता है कि यह डोमेन परत में दृढ़ता की चिंताओं को सम्मिलित कर रहा है, जो कुछ ऐसा है जिसे हम टालने के लिए प्रयास करना चाहते हैं।

क्या ऐसा कुछ है जो मुझे बाहरी कॉन्फ़िगरेशन फ़ाइल या शायद डोमेन मॉडल से अलग डीटीओ का उपयोग करके चकमा देने का प्रयास करना चाहिए? या क्या दृढ़ता और डोमेन परतों के बीच आम तौर पर स्वीकार्य माना जाता है?

Answer 1

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

हालांकि, मैं इस प्रणाली को बदलती व्यावसायिक आवश्यकताओं के प्रकाश में फिर से डिजाइन कर रहा हूं, और मैं फिर से उन चिंताओं को अलग करने की ओर झुका रहा हूं। मैं नए डिजाइन में केवल कुछ ही दिन हूं, लेकिन पहले से ही मैं खुद को एक ऑब्जेक्ट पसंद करता हूं जो इन-मेमोरी चिंताओं के ऑब्जेक्ट का प्रतिनिधित्व करता है जबकि एक अलग दृढ़ता-आधारित ऑब्जेक्ट का उपयोग डेटाबेस में अपने राज्य परिवर्तनों को संग्रहीत करने के लिए किया जाता है। उदाहरण के लिए, मेरे पास दृढ़ता के लिए Lead है और समानांतर ActiveLead लेनदेन में रहता है।

मुझे अभी तक विश्वास नहीं है कि यह सबसे अच्छी विधि है, लेकिन यह एक आंत स्तर पर समझ में आता है। मुझे दृढ़ता-अज्ञेय संग्रह का संग्रह होना चाहिए - nay, persistence- अज्ञानी - मानक CRUD सरलीकरण के संबंध में डेटाबेस लेन-देन में मेमोरी-निवासी रहने वाली वस्तुओं की सेट। फिर भी मैं समझता हूं कि अंत में सभी डेटाबेस संचालन सीआरयूडी के रूप में लागू किए जाते हैं। दोनों दुनिया को टक्कर लगी होगी, और यह चाल उन्हें सद्भाव में नृत्य करने में है।

डोमेन ऑब्जेक्ट्स पर हाइबरनेट एनोटेशन? यह मेरे विचार में रखरखाव की आसानी के कार्यान्वयन बनाम आसानी के बीच एक अच्छा समझौता है।

Answer 2

मेरी राय में डोमेन ऑब्जेक्ट्स को डुप्लिकेट करने की आवश्यकता नहीं है ताकि वे आपकी दृढ़ता परत से अलग हो सकें। यह हाथ में डुप्लिकेट कोड काम करता है और यह डीटीओ के समान वस्तुओं का उपयोग करके पूरी तरह से करने योग्य है। यदि आवश्यक हो तो आप हमेशा अलग वर्गों का उपयोग कर सकते हैं यदि इसकी आवश्यकता हो, लेकिन मैं इसे अंगूठे का नियम नहीं बनाऊंगा, यह आपको समय लगेगा और हम सभी जानते हैं कि समय मूल्यवान है।

Answer 3

मैंने हाल ही में एक जटिल जटिल प्रणाली पर काम किया है जिसमें एक अलग दृढ़ता परत थी, और यह गधे में एक बड़ा दर्द था और रखरखाव के लिए बहुत बुरा था। आप मूल रूप से यागनी और एकल जिम्मेदारी के सिद्धांतों के बीच एक संघर्ष को देख रहे हैं। मेरी राय में, यागनी अधिक महत्वपूर्ण है (हां, इसे अक्सर अनदेखा भी किया जाता है)। (वे अगर

मैं अधिकांश मामलों में कहेंगे, यह डोमेन सीधे वस्तुओं आप एक ORM उपयोग कर रहे हैं लागू करने के लिए काफी बेहतर है, जब तक आप ठोस आवश्यकताओं है कि हठ संस्थाओं के लिए मजबूर अलग ढंग से बनाया जाता है करने के लिए बिल्कुल वही संरचना है, हाथीदांत टावर तर्कों को छोड़कर उन्हें अलग करने का कोई कारण नहीं है)।

यह सुनिश्चित करने के लिए: हमेशा एक अलग सेवा/डीएओ परत में वास्तविक दृढ़ता सामग्री (कॉलिंग ओआरएम फ़ंक्शंस) करें! इस तरह, अगर आपको लगता है कि आपको इसकी आवश्यकता है तो बाद में एक दृढ़ता परत पेश करना आसान है।

Answer 4

संक्षिप्त उत्तर: मुझे लगातार, समृद्ध, डोमेन ऑब्जेक्ट पसंद हैं।

लांग जवाब:

लगभग 10 साल मैं एक काफी बड़े प्रणाली ~ स्प्रिंग और हाइबरनेट का उपयोग कर 500k एलओसी पर काम किया है। शुरुआत में, हमने "लेनदेन स्क्रिप्ट" (फाउलर देखें) दृष्टिकोण से शुरुआत की, आंशिक रूप से क्योंकि हम हाइबरनेट पर भरोसा नहीं करते थे। हालांकि, थोड़े समय में, हम हाइबरनेट पर भरोसा करने आए और काफी शुद्ध ओओ में अपने पहले के प्रशिक्षण के कारण, मैं एक डोमेन संचालित डिजाइन दृष्टिकोण के साथ संयुक्त क्षणिक दृढ़ता में एक बड़ा आस्तिक बन गया। हम मूल रूप से ओडीबीएमएस के साथ समर्थित होने के रूप में हमारे सिस्टम के बारे में सोचने आए (बहुत सारे छोटे रिसाव :-))।

मैंने अपने आर्किटेक्चर को "डोमेन कर्नेल" कहा क्योंकि पुस्तक डीडीडी अभी तक लिखी नहीं गई थी। यह हाइबरनेट के प्रारंभिक दिनों में था, इसलिए डोमेन मॉडल एनोटेशन के साथ प्रदूषित नहीं हुआ था। एक्सएमएल मैपिंग में दृढ़ता की अलग चिंता अलग रखी गई थी।

फिर से, समय के साथ, हम डोमेन परत में व्यवहार को धक्का देने में बेहतर हो गए। हमारे पास एक सुंदर पारंपरिक नियंत्रक था -> सेवा -> दाओ -> डोमेन लेयरिंग योजना जिसे संकलन-समय निर्भरताओं के साथ लागू किया गया था। मैंने समय के साथ जो देखा वह यह है कि इस मॉडल ने हमारे सिस्टम के लिए बहुत अच्छा काम किया है, जो योजना सेटअप, व्यापार, लेखा, अनुपालन परीक्षण, बिक्री, ब्रांडिंग इत्यादि सहित 401 (के) योजना प्रबंधन के काफी जटिल डोमेन के हर पहलू का प्रतिनिधित्व करता है। डोमेन मॉडल में मौजूदा सुविधाओं के संदर्भ में नई सुविधाओं को बनाने में सक्षम होने में एक समृद्ध डोमेन मॉडल (अपेक्षाकृत) पारदर्शी "जादुई" दृढ़ता के साथ महत्वपूर्ण था।

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

इस दृष्टिकोण ने हमें एक बहुत छोटी टीम के साथ उच्च गुणवत्ता वाले सॉफ्टवेयर बनाने की अनुमति दी (हम एक स्क्रम टीम थे)।

तो, मुझे लगातार डोमेन ऑब्जेक्ट्स में एक आस्तिक मानें। पता नहीं है कि मेरी कहानी मदद करता है, लेकिन मैं साझा करना चाहता था।

Answer 5

क्या डोमेन में दृढ़ता एनोटेशन एक बुरी आदत है?

हाँ। नोएसक्यूएल के उदय के साथ, आप एकल दृढ़ता रणनीति पर भरोसा नहीं कर सकते हैं।

उदाहरण के लिए, आज मैं अपने डोमेन ऑब्जेक्ट्स (मॉर्फिया का उपयोग करके कहता हूं) MongoDB में बना रहा हूं। क्या होगा अगर कल मैं डोमेन ऑब्जेक्ट्स को Neo4j पर कायम रखना चाहता हूं?

या, कोई भी मूल्यांकन के लिए केवल तीन प्रकार के डेटाबेस जैसे संबंध (पोस्टग्रेस/माईएसक्यूएल), मोंगोडीबी (दस्तावेज़ स्टोर) और नियो 4 जे (ग्राफ डेटाबेस) को डोमेन ऑब्जेक्ट्स को जारी रखना चाहता है। एक रणनीति पैटर्न मदद कर सकता है के रूप में लगातार रणनीति पासिंग:

इन सभी मामलों में, बेहतर अलग हठ रणनीति के बजाय डोमेन पर निर्भर वस्तुओं

बेस्ट प्रैक्टिस है। लेकिन अपने वर्ग/वस्तुओं को डिजाइन करते समय सावधान रहना होगा।

Answer 6

मैं समृद्ध डोमेन ऑब्जेक्ट्स पसंद करूंगा जिन पर एनोटेशन हैं।यहां तक ​​कि इवांस भी इस दृष्टिकोण का उपयोग अपने sample app में करते हैं। वह एनोटेशन के बजाय एक्सएमएल का उपयोग करता है लेकिन वह अभी भी वही ऑब्जेक्ट्स बना रहता है।

शायद डोमेन और दृढ़ता को अलग करने के लिए यह और अधिक साफ है, लेकिन भविष्य में संभावित रूप से एक अलग डीबी तकनीक का चयन करने में सक्षम होने के लिए नहीं। यह जटिलता नरक के नीचे रास्ता है और मिस्टर यागनी आपको काट देगा।

Answer 7

मेरा मानना ​​है कि मैं अपने डोमेन पर एनोटेशन का उपयोग करूंगा यदि मैं पहले से ही दृढ़ता फ्रेमवर्क के साथ निर्णय ले रहा हूं, जिसका उपयोग मैं करने जा रहा हूं, हालांकि, यदि आप Hexagonal आर्किटेक्चर और टीडीडी का पालन करते हैं तो एक्सएमएल अधिक सुविधाजनक होगा। यदि आप अपने डोमेन को विशिष्ट ढांचे के साथ पहले से एनोटेट करते हैं, तो आपकी इच्छा लगातार एकीकरण के साथ मिल जाएगी और प्रौद्योगिकी/ढांचा अज्ञेय होने के उद्देश्य से कोर कार्यक्षमता का परीक्षण करने में असमर्थ होगी।