जब भी कोई डेवलपर पूछता है कि "यह करने का क्या मतलब है?", तो उनका वास्तव में क्या मतलब है "मुझे कोई उपयोग मामला नहीं दिखता है जहां ऐसा करने से लाभ मिलता है"। उस अंत तक, मैं आपको कुछ उदाहरण दिखाता हूं।
सभी उदाहरण इस सरल डेटा मॉडल पर आधारित होंगे:
एक Personइकाई में पाँच गुण होते हैं:Id, FirstName, LastName, Age, CityId
और आप मान सकते हैं कि एप्लिकेशन इस डेटा का उपयोग कई विविध तरीकों (रिपोर्ट, रूप, पॉपअप, ...) में करता है।
संपूर्ण एप्लिकेशन पहले से मौजूद है। मेरे द्वारा उल्लेखित सब कुछ मौजूदा कोडबेस में बदलाव है। यह याद रखना महत्वपूर्ण है।
उदाहरण 1 - अंतर्निहित डेटा संरचना को बदलना - बिना डीटीओ के
आवश्यकताएँ बदल गई हैं। व्यक्ति की आयु को सरकार के डेटाबेस से गतिशील रूप से पुनर्प्राप्त करने की आवश्यकता है (चलो उनके पहले और अंतिम नाम के आधार पर मान लें)।
चूँकि आपको Ageअब स्थानीय स्तर पर मूल्य को संग्रहीत करने की आवश्यकता नहीं है, इसलिए इसे Personइकाई से निकालने की आवश्यकता है । यह समझना महत्वपूर्ण है कि इकाई डेटाबेस डेटा का प्रतिनिधित्व करती है , और इससे अधिक कुछ नहीं। यदि यह डेटाबेस में नहीं है, तो यह इकाई में नहीं है।
जब आप सरकार की वेब सेवा से आयु प्राप्त करते हैं, तो उसे एक अलग ऑब्जेक्ट (या इंट) में संग्रहीत किया जाएगा।
लेकिन आपका दृश्य अभी भी एक उम्र प्रदर्शित करता है। Person.Ageसंपत्ति का उपयोग करने के लिए सभी विचार स्थापित किए गए हैं, जो अब मौजूद नहीं है। एक समस्या खुद को प्रस्तुत करती है: किसी व्यक्ति को संदर्भित करने वाले सभी विचारों Ageको ठीक करने की आवश्यकता होती है ।
उदाहरण 2 - अंतर्निहित डेटा संरचना को बदलना - डीटीओ के साथ
पुरानी व्यवस्था में, वहाँ भी है PersonDTOएक ही पाँच गुणों के साथ इकाई: Id, FirstName, LastName, Age, CityId। पुनः प्राप्त करने के बाद Person, सेवा परत इसे एक में परिवर्तित करती है PersonDTOऔर फिर इसे वापस लौटा देती है।
लेकिन अब, आवश्यकताएँ बदल गई हैं। व्यक्ति की आयु को सरकार के डेटाबेस से गतिशील रूप से पुनर्प्राप्त करने की आवश्यकता है (चलो उनके पहले और अंतिम नाम के आधार पर मान लें)।
चूँकि आपको Ageअब स्थानीय स्तर पर मूल्य को संग्रहीत करने की आवश्यकता नहीं है, इसलिए इसे Personइकाई से निकालने की आवश्यकता है । यह समझना महत्वपूर्ण है कि इकाई डेटाबेस डेटा का प्रतिनिधित्व करती है , और इससे अधिक कुछ नहीं। यदि यह डेटाबेस में नहीं है, तो यह इकाई में नहीं है।
हालाँकि, चूंकि आपके पास एक मध्यस्थ है PersonDTO, इसलिए यह देखना महत्वपूर्ण है कि यह वर्ग संपत्ति रख सकता Ageहै। सर्विस लेयर को लाया जाएगा Person, इसे कन्वर्ट करें , PersonDTOफिर यह सरकार की वेब सर्विस से उस व्यक्ति की उम्र भी लेगा, उस वैल्यू को स्टोर करेगा PersonDTO.Ageऔर उस ऑब्जेक्ट को पास करेगा।
यहाँ महत्वपूर्ण हिस्सा यह है कि जो कोई भी सेवा की परत का उपयोग करता है उसे पुराने और नए सिस्टम के बीच अंतर नहीं दिखता है । इसमें आपका दृश्य शामिल है। पुरानी प्रणाली में, इसे एक पूर्ण PersonDTOवस्तु प्राप्त हुई । और नई प्रणाली में, यह अभी भी एक पूर्ण PersonDTOवस्तु प्राप्त करता है । विचारों को अद्यतन करने की आवश्यकता नहीं है ।
जब हम चिंताओं के वाक्यांश पृथक्करण का उपयोग करते हैं, तो इसका मतलब है : दो अलग-अलग चिंताएं होती हैं (डेटाबेस में डेटा संग्रहीत करना, सामने वाले को डेटा प्रस्तुत करना) और उन्हें प्रत्येक अलग डेटा प्रकार की आवश्यकता होती है। भले ही उन दो डेटा प्रकारों में एक ही डेटा शामिल हो, जो कि भविष्य में बदल सकते हैं।
दिए गए उदाहरण में, Ageदो डेटा प्रकारों के बीच एक अंतर है: Person(डेटाबेस इकाई) को एक की आवश्यकता नहीं है Age, लेकिन PersonDTO(फ्रंटेंड डेटा प्रकार) को इसकी आवश्यकता नहीं है।
शुरुआत से ही चिंताओं (= अलग डेटा प्रकार बनाने) को अलग करके, कोडबेस डेटा मॉडल में किए गए परिवर्तनों के लिए अधिक लचीला है।
आप तर्क दे सकते हैं कि जब एक नया कॉलम डेटाबेस में जोड़ा जाता है, तो डीटीओ ऑब्जेक्ट होने का मतलब है कि आपको इकाई और डीटीओ दोनों में संपत्ति जोड़कर दोहरा काम करना होगा। यह तकनीकी रूप से सही है। इसे एक के बजाय दो वर्गों को बनाए रखने के लिए थोड़े अतिरिक्त प्रयास की आवश्यकता होती है।
हालांकि, आपको आवश्यक प्रयास की तुलना करने की आवश्यकता है। जब एक या अधिक नए कॉलम जोड़े जाते हैं, तो कुछ गुणों को कॉपी / पेस्ट करना लंबे समय तक नहीं रहता है। जब डेटा मॉडल संरचनात्मक रूप से बदलता है, तो दृश्यपटल बदलने के लिए, संभवतः उन तरीकों से जो केवल रनटाइम पर कीड़े पैदा करते हैं (और संकलन समय पर नहीं), काफी अधिक प्रयास लेता है, और इसे बग्स के लिए शिकार करने के लिए डेवलपर (ओं) की आवश्यकता होती है।
मैं आपको और उदाहरण दे सकता हूं लेकिन सिद्धांत हमेशा एक ही रहेगा।
संक्षेप में
- अलग-अलग जिम्मेदारियों (चिंताओं) को एक-दूसरे से अलग होकर काम करने की जरूरत है। उन्हें किसी भी संसाधन जैसे डेटा वर्ग (जैसे
Person) को साझा नहीं करना चाहिए
- सिर्फ इसलिए कि एक इकाई और उसके डीटीओ में समान गुण हैं, इसका मतलब यह नहीं है कि आपको उन्हें एक ही इकाई में विलय करने की आवश्यकता है। कोने मत काटो।
- एक और अधिक स्पष्ट उदाहरण के रूप में, मान लें कि हमारे डेटाबेस में देश, गीत और लोग हैं। इन सभी संस्थाओं में ए
Name। लेकिन सिर्फ इसलिए कि उनके पास एक Nameसंपत्ति है, इसका मतलब यह नहीं है कि हमें उन्हें एक साझा EntityWithNameआधार वर्ग से विरासत में लेना चाहिए । विभिन्न Nameगुणों का कोई सार्थक संबंध नहीं है।
- गुणों में से एक को कभी भी बदलना चाहिए (उदाहरण के लिए एक गीत का
Nameनाम बदल दिया जाता है Title, या एक व्यक्ति को एक हो जाता है FirstNameऔर LastName), उन्हें आपको विरासत में प्राप्त करने के लिए अधिक प्रयास करना होगा, जिसकी आपको पहली जगह में भी आवश्यकता नहीं थी ।
- यद्यपि उतने स्पष्ट नहीं, आपके तर्क कि आपको एक इकाई होने पर डीटीओ की आवश्यकता नहीं है। अब आप देख रहे हैं , लेकिन आप भविष्य के किसी भी बदलाव की तैयारी नहीं कर रहे हैं। यदि इकाई और डीटीओ बिल्कुल समान हैं, और यदि आप यह गारंटी दे सकते हैं कि डेटा मॉडल में कभी कोई बदलाव नहीं होगा; तब आप सही हैं कि आप डीटीओ को छोड़ सकते हैं। लेकिन बात यह है कि आप कभी भी गारंटी नहीं दे सकते कि डेटा मॉडल कभी नहीं बदलेगा।
- अच्छा अभ्यास हमेशा तुरंत भुगतान नहीं करता है। यह भविष्य में भुगतान करना शुरू कर सकता है, जब आपको किसी पुराने एप्लिकेशन को फिर से शुरू करना होगा।
- मौजूदा कोडबेस का मुख्य हत्यारा कोड गुणवत्ता को कम करने देता है, लगातार कोडबेस को बनाए रखना और अधिक कठिन बना देता है, जब तक कि यह स्पेगेटी कोड के बेकार गंदगी में न हो जाए जो कि अकल्पनीय है।
- अच्छा अभ्यास, जैसे कि गेट टू से चिंताओं को अलग करने का उद्देश्य, खराब रखरखाव के उस फिसलन ढलान से बचने के लिए, ताकि कोडबेस को यथासंभव लंबे समय तक बनाए रखा जा सके।
अलग-अलग चिंताओं पर विचार करने के लिए अंगूठे के नियम के रूप में, इस तरह से सोचें:
मान लीजिए कि हर चिंता (यूआई, डेटाबेस, तर्क) एक अलग स्थान पर एक अलग व्यक्ति द्वारा नियंत्रित की जाती है। वे केवल ईमेल द्वारा संवाद कर सकते हैं।
एक अलग कोडबेस में, एक विशेष चिंता का एक परिवर्तन केवल एक व्यक्ति द्वारा नियंत्रित किया जाना चाहिए:
- उपयोगकर्ता इंटरफ़ेस को बदलने में केवल यूआई देव शामिल है।
- डेटा संग्रहण विधि को बदलने में केवल डेटाबेस देव शामिल है।
- व्यापार तर्क को बदलने में केवल व्यवसाय देव शामिल हैं।
यदि ये सभी डेवलपर्स एक ही Personइकाई का उपयोग कर रहे थे , और इकाई के लिए एक मामूली बदलाव किया गया था, तो सभी को प्रक्रिया में शामिल होना होगा।
लेकिन हर परत के लिए अलग-अलग डेटा कक्षाओं का उपयोग करके, यह मुद्दा उतना प्रचलित नहीं है:
- जब तक डेटाबेस देव एक वैध
PersonDTOवस्तु को वापस कर सकता है , तब तक व्यवसाय और यूआई देव को परवाह नहीं है कि वह बदल गया है कि डेटा कैसे संग्रहीत / पुनर्प्राप्त किया जाता है।
- जब तक व्यवसाय देव डेटाबेस में डेटा संग्रहीत करता है, और दृश्यपटल को आवश्यक डेटा प्रदान करता है, तब तक डेटाबेस और यूआई देवों को परवाह नहीं है यदि उसने अपने व्यावसायिक नियमों को फिर से बनाने का फैसला किया है।
- जब तक यूआई को 'पर्सनव्हीमॉडल' के आसपास डिजाइन किया जा सकता है, तब तक यूआई देव यूआई का निर्माण कर सकते हैं। डेटाबेस और व्यवसाय देवों को परवाह नहीं है कि यह कैसे किया जाता है, क्योंकि यह उन्हें प्रभावित नहीं करता है।
यहाँ प्रमुख वाक्यांश है क्योंकि यह उन्हें प्रभावित नहीं करता है । चिंताओं के एक अलग पृथक्करण को लागू करने के लिए अन्य पार्टियों को प्रभावित करने (और इसलिए शामिल करने के लिए) को कम से कम करना चाहता है।
बेशक, कुछ बड़े बदलाव एक से अधिक लोगों को शामिल करने से बच नहीं सकते हैं, उदाहरण के लिए जब डेटाबेस में एक पूरी तरह से नई इकाई जोड़ी जाती है। लेकिन किसी एप्लिकेशन के जीवनकाल में आपके द्वारा किए जाने वाले छोटे बदलावों को कम न समझें। प्रमुख परिवर्तन एक संख्यात्मक अल्पसंख्यक हैं।
What's the benefit of these conversions?उपभोक्ताओं को दिए जाने वाले डेटा मॉडल (प्रतिनिधित्व) से दृढ़ता डेटा मॉडल को डिकूप करना। एसई में डिकॉउलिंग के लाभों पर व्यापक रूप से चर्चा की गई है, हालांकि डीटीओ के नीचे का उद्देश्य एकल प्रतिक्रिया में इकट्ठा करना है, क्योंकि ग्राहकों को सर्वर को कॉल बचाने के लिए आवश्यक कई जानकारी के रूप में समझा जाता है। क्या संचार क्लाइंट-सर्वर चिकनी बनाता है।