डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट्स) का उपयोग करने का क्या मतलब है?

132

डीटीओ का उपयोग करने की बात क्या है और क्या यह एक आउट डेटेड अवधारणा है? मैं डेटा को स्थानांतरित करने और बनाए रखने के लिए दृश्य परत में POJO का उपयोग करता हूं । क्या इन पीओजेओ को डीटीओ के विकल्प के रूप में माना जा सकता है?

java design-patterns

— विनोथ कुमार सी.एम.
स्रोत

10

लेकिन POJO को DTO और DTO को POJO के साथ लागू किया जा सकता है। आप सेब और संतरे की तुलना कर रहे हैं।

— व्यंग्यात्मक

3

अच्छे विचारों को पुराना क्यों होना चाहिए? लिस्प को देखो। चुटकुलों के अलावा, मैं व्यंग्य से सहमत हूं: मैं आम तौर पर POOO का उपयोग करके डीटीओ को लागू करता हूं। मैं अब भी लगता है डीटीओ का बहुत ही सरल (चुंबन) और उपयोगी अवधारणा है।

— जियोर्जियो

कोई मतलब नहीं है, यह एक विरोधी पैटर्न है, देखें: डेटा ट्रांसफर ऑब्जेक्ट एक शर्म की बात है

— yegor256

115

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

डीटीओ एक मूलभूत अवधारणा है, जो पुरानी नहीं है।

— thed
स्रोत

9

आप उन्हें अलग-अलग नामों के तहत पा सकते हैं, हालांकि हर कोई इन दिनों पहिया को फिर से

— मजबूत

3

जैसे "वैल्यू ऑब्जेक्ट"।

— TheD

2

@linkerro: यह सच है: मुझे लगता है कि बहुत से लोगों को सामान के बारे में पढ़ने में अधिक समय बिताना चाहिए जो पहले से ही खुद को फिर से आविष्कार करने के बजाय आविष्कार किया गया है। पुनः आविष्कार किया गया सामान हमेशा कम परिपक्व होगा।

— जियोर्जियो

10

@ जियोर्जियो वहाँ बहुत सारे देवता हैं जो अभी भी उन विचारों के साथ चल रहे हैं जिन्हें कभी भी जमीन से बाहर नहीं जाना चाहिए था। काश और अधिक देवों ने उनके द्वारा पढ़े जाने वाले हर विचार पर सवाल उठाया।

— एरिक रिपेन

59

डीटीओ एक अवधारणा के रूप में (ऑब्जेक्ट जिसका उद्देश्य सर्वर द्वारा क्लाइंट को वापस किए जाने के लिए डेटा एकत्र करना है) निश्चित रूप से पुराना नहीं है।

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

हालाँकि, यह धारणा सिर्फ सादे गलत के बजाय पुरानी है, इसका कारण यह है कि कुछ (मुख्य रूप से पुराने) फ्रेमवर्क / प्रौद्योगिकियों को इसकी आवश्यकता होती है, क्योंकि उनके डोमेन और व्यू मॉडल POJOS नहीं हैं और इसके बजाय सीधे फ्रेमवर्क से बंधा हुआ है।

सबसे विशेष रूप से, EJB 3 मानक से पहले J2EE में एंटिटी बीन्स POJOs नहीं थे और इसके बजाय ऐप सर्वर द्वारा निर्मित प्रॉक्सी ऑब्जेक्ट थे - उन्हें क्लाइंट को भेजना संभव नहीं था, इसलिए आपके पास एक अलग डीटीओ परत खो देने के बारे में कोई विकल्प नहीं था। - यह अनिवार्य था।

— माइकल बोर्गवर्ड
स्रोत

2

एक यूआई देव के रूप में एक और अधिक सामान्य भूमिका के लिए मजबूर किया गया है जो मैंने निश्चित रूप से हमारे कोडबेस स्टेप में Mapper.Map घटना को पाया है। डीटीओ सिर्फ मैप ही क्यों नहीं कर सकते?

— एरिक रिपेन

1

@ErikReppen मुख्य लाभ आपके डोमेन मॉडल और DTO के डिकूपिंग है। यदि आपका डीटीओ स्वयं मैप करता है, तो उसे आपके डोमेन मॉडल का संदर्भ चाहिए।

— अलेक्जेंडर डर्क

17

यद्यपि डीटीओ एक पुराना पैटर्न नहीं है, लेकिन इसे अक्सर अनावश्यक रूप से लागू किया जाता है, जिससे यह पुराना प्रतीत हो सकता है।

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

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

बीन मान्यकरण एनोटेशन पर विचार करें। आपके JPA एंटिटीज़ को संभवतः @NotNull और @Size सत्यापन के साथ एनोटेट किया गया है। यदि आप एक DTO का उपयोग कर रहे हैं, तो आप अपने DTO में इन मान्यताओं को दोहराना चाहेंगे ताकि आपके दूरस्थ इंटरफ़ेस का उपयोग करने वाले ग्राहकों को यह पता लगाने के लिए संदेश भेजने की आवश्यकता न हो कि वे मूल सत्यापन विफल हो गए हैं। अपने डीटीओ और एंटिटी के बीच बीन वैलिडेशन एनोटेशन को कॉपी करने के सभी अतिरिक्त कार्यों की कल्पना करें, लेकिन अगर आपका दृश्य और एंटिटीज एक ही जेवीएम के भीतर चल रहे हैं, तो इस अतिरिक्त काम को लेने की कोई आवश्यकता नहीं है: बस एंटिटीज़ का उपयोग करें।

एंटरप्राइज एप्लीकेशन आर्किटेक्चर के कैटलॉग पैटर्न की IAmTheDude की लिंक डीटीओ का संक्षिप्त विवरण प्रदान करती है, और यहां और अधिक संदर्भ हैं जिन्हें मैंने प्रकाशित किया:

— डेविड्स
स्रोत

3

वहाँ वाक्य है: "..., लेकिन अगर आपके ManagedBeans और Entities एक ही JVM के भीतर चल रहे हैं, तो DTO पैटर्न का उपयोग करने के लिए बहुत कम लाभ है" । वहाँ कंपनियों में कई मध्यम आकार के ऐप हैं जो बिना किसी लाभ के डीटीओ पैटर्न को बेवकूफी से लागू करते हैं। यह सिर्फ एक बेकार "कॉपी लेयर" जोड़ता है। जिन लोगों ने ये सिस्टम बनाया है, उन्हें यह एहसास नहीं हुआ कि लेनदेन समाप्त होने पर जावा ईई 5+ इकाई प्रबंधक संस्थाओं को अलग कर देता है और उन्हें वास्तविक डीटीओ बना देता है। तो, सिंगल-जेवीएम वेबैप्स के लिए, पैटर्न का प्रकार पुराना है । ऐसा लगता है कि J2EE बैकएंड डेवलपर्स के अवशेष ...

— कावु

लेकिन "JSF ManagedBean" और "JPA Entity" क्या है? यदि वे पुराने नहीं हैं, तो आपको उन्हें रूपरेखा और भाषा अज्ञेय शब्दों का उपयोग करके समझाने में सक्षम होना चाहिए।

— यू अवलोस

8

बिलकुल नहीं! अभी हाल ही में मैंने आपके द्वारा उपयोग की जाने वाली व्यावसायिक वस्तु के बजाय डीटीओ का उपयोग करने के बारे में बेहतर तरीके से सीखा है (संभवतः आपके ORM मैपर के लिए)।

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

— जूरी
स्रोत

1

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

— zquintana
स्रोत