डेटा ट्रांसफर ऑब्जेक्ट क्या है?

Question

डेटा ट्रांसफर ऑब्जेक्ट क्या है?

MVC में मॉडल कक्षाएं DTO हैं, और यदि नहीं तो क्या अंतर हैं और क्या हमें दोनों की आवश्यकता है?

Comments

@ yegor256 और इस तथ्य को, उस लेख की पुस्तक यह जानती है कि एपीआई से डेटा कैसे प्राप्त किया जाए और डेटा को डीबी में कैसे स्टोर किया जाए, और इसलिए एसआरपी का उल्लंघन करना ठीक है?

— बेतालिस्ता

Answer 1

डेटा ट्रांसफर ऑब्जेक्ट एक ऐसी वस्तु है जिसका उपयोग डेटा को एनकैप्सुलेट करने के लिए किया जाता है, और इसे किसी एप्लिकेशन के एक सबसिस्टम से दूसरे में भेजा जाता है।

डीटीओ को आमतौर पर एन-टियर एप्लिकेशन में सेवाओं की परत का उपयोग स्वयं और यूआई परत के बीच डेटा स्थानांतरित करने के लिए किया जाता है। यहां मुख्य लाभ यह है कि यह वितरित अनुप्रयोगों में तार पर भेजे जाने वाले डेटा की मात्रा को कम करता है। वे एमवीसी पैटर्न में शानदार मॉडल भी बनाते हैं।

डीटीओ के लिए एक अन्य उपयोग विधि कॉल के लिए मापदंडों को एनकैप्सुलेट करना हो सकता है। यह उपयोगी हो सकता है यदि कोई विधि 4 या 5 से अधिक पैरामीटर लेती है।

DTO पैटर्न का उपयोग करते समय, आप DTO कोडांतरकों का उपयोग भी करेंगे। डोमेन ऑब्जेक्ट्स से DTOs बनाने के लिए कोडांतरक का उपयोग किया जाता है, और इसके विपरीत।

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

Comments

"डीटीओ एमवीसी पैटर्न में शानदार मॉडल बनाते हैं" - लेकिन क्या किसी मॉडल में ऑब्जेक्ट के सभी डेटा नहीं होंगे और डीटीओ को डेटा के भाग के साथ अनुकूलित किया जाना चाहिए? अगर मेरे पास मॉडल A है और मुझे इसे दो उप-प्रणालियों में पास करने की आवश्यकता है, तो प्रत्येक के संबंधित क्षेत्रों के साथ A_DTO_1 और A_DTO_2 होंगे? "DTO हो सकता है कि मैथड कॉल के लिए पैरामीटर्स को एनकैप्सुलेट किया जाए" -> तो हर वर्ग जो रैप्स पैरामीटर है डीटीओ है भले ही यह डिस्ट्रीब्यूटेड सिस्टम न हो? एमवीसी डोमेन ऑब्जेक्ट में मॉडल नहीं हैं?

— यारन नोह

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

— बेनी हैलट

"डीटीओ के लिए एक और उपयोग विधि कॉल के लिए मापदंडों को इनकैप्सुलेट करने के लिए हो सकता है। यह उपयोगी हो सकता है यदि कोई विधि 4 या अधिक पैरामीटर लेती है।" यह वास्तव में एक एंटी-पैटर्न है जिसे पोल्टरजिस्ट या जिप्सी वैगन वर्ग कहा जाता है। यदि आपकी विधि को 4 तर्कों की आवश्यकता है, तो इसे 4 दें, किसी ऑब्जेक्ट को विधि या वर्ग में ले जाने के लिए एक वर्ग न बनाएं।

— विक्स डेस

@Ix, अच्छी बात है। मैं तर्क देता हूं कि यह ठीक है अगर यह शब्दशः सही है (यदि आप गुणों के साथ सेटिंग्स वर्ग को मान के बजाय गुणों के रूप में पास करते हैं)। आपको जो नहीं करना चाहिए, वह एक ही वस्तु को पारित करने के लिए सभी तर्कों में फेंक दिया जाता है, क्योंकि वे बहुत अच्छी तरह से असंबंधित हो सकते हैं और बाद में बुरे सपने आने का कारण बन सकते हैं।

— अराम कोचरन

डीटीओ का उपयोग तरीकों की कॉल के लिए मापदंडों को एनकैप्सुलेट करने के लिए नहीं किया जाना चाहिए (जो उन्हें स्थानीयडॉट्स बना देगा), उन्हें दूरस्थ इंटरफेस के संदर्भ में पेश किया गया था: martinfowler.com/bliki/LocalDTO.html

— Rui

Answer 2

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

Answer 3

एक डीटीओ एक गूंगा वस्तु है - यह सिर्फ गुण रखता है और इसमें गेटर्स और सेटर हैं, लेकिन किसी भी महत्व का कोई अन्य तर्क नहीं है (शायद तुलना के अलावा अन्य) (या बराबर) (कार्यान्वयन)।

आमतौर पर MVC में मॉडल कक्षाएं (यहां .net MVC मानकर) DTO, या DTO के संग्रह / समुच्चय हैं

Comments

आप जो वर्णन कर रहे हैं वह एक LocalDTO है: martinfowler.com/bliki/LocalDTO.html

— रुई

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

— अमिताभ

Answer 4

सामान्य मूल्य में वस्तुओं को अपरिवर्तनीय होना चाहिए। जैसे कि Java में Integer या String ऑब्जेक्ट। हम सॉफ्टवेयर परतों के बीच डेटा स्थानांतरित करने के लिए उनका उपयोग कर सकते हैं। यदि सॉफ्टवेयर परतें या सेवाएं विभिन्न दूरस्थ नोड्स में चल रही हैं, जैसे कि माइक्रोसेवा परिवेश में या विरासत जावा एंटरप्राइज ऐप में। हमें दो वर्गों की लगभग सटीक प्रतियाँ बनानी चाहिए। यह वह जगह है जहां हम डीटीओ से मिले थे।

|-----------|                                                   |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------|                                                   |--------------|

विरासत में जावा एंटरप्राइज सिस्टम डीटीओ में विभिन्न ईजेबी सामान हो सकते हैं।

मुझे नहीं पता कि यह सबसे अच्छा अभ्यास है या नहीं, लेकिन मैं व्यक्तिगत रूप से इस तरह से अपने स्प्रिंग एमवीसी / बूट प्रोजेक्ट्स में मूल्य वस्तुओं का उपयोग करता हूं:

        |------------|         |------------------|                             |------------|
-> Form |            | -> Form |                  | -> Entity                   |            |
        | Controller |         | Service / Facade |                             | Repository |
<- View |            | <- View |                  | <- Entity / Projection View |            |
        |------------|         |------------------|                             |------------|

नियंत्रक परत को पता नहीं है कि संस्थाएं क्या हैं। यह प्रपत्र और दृश्य मान ऑब्जेक्ट के साथ संचार करता है । फॉर्म ऑब्जेक्ट्स में JSR 303 वैलिडेशन एनोटेशन (उदाहरण के लिए @NNNull) और व्यू वैल्यू ऑब्जेक्ट हैं में कस्टम क्रमांकन के लिए जैक्सन एनोटेशन हैं। (उदाहरण @JsonIgnore के लिए)

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

User Service ----> XX CANNOT CALL XX ----> Order Service

कुछ ओ.आर.एम. फ्रेमवर्क में अतिरिक्त इंटरफेस या कक्षाओं का उपयोग करके प्रक्षेपण की क्षमता है। इसलिए रिपॉजिटरी सीधे ऑब्जेक्ट्स को वापस कर सकते हैं। वहां आपके लिए एक अतिरिक्त परिवर्तन की आवश्यकता नहीं है।

उदाहरण के लिए यह हमारी उपयोगकर्ता इकाई है:

@Entity
public final class User {
    private String id;
    private String firstname;
    private String lastname;
    private String phone;
    private String fax;
    private String address;
    // Accessors ...
}

लेकिन आपको उन उपयोगकर्ताओं की पृष्ठांकित सूची वापस करनी चाहिए जिनमें सिर्फ आईडी, फर्स्टनाम, लास्टनाम शामिल हैं। तब आप ORM प्रोजेक्शन के लिए व्यू वैल्यू ऑब्जेक्ट बना सकते हैं।

public final class UserListItemView {
    private String id;
    private String firstname;
    private String lastname;
    // Accessors ...
}

आप आसानी से रिपोजिटरी लेयर से पृष्ठांकित परिणाम प्राप्त कर सकते हैं। वसंत के लिए धन्यवाद आप अनुमानों के लिए सिर्फ इंटरफेस का उपयोग कर सकते हैं।

List<UserListItemView> find(Pageable pageable);

अन्य रूपांतरण संचालन BeanUtils.copyविधि के लिए चिंता न करें ठीक काम करता है।

Answer 5

1. मेरे लिए इस सवाल का सबसे अच्छा जवाब है कि डीटीओ क्या है, डीटीओ ऐसी सरल वस्तुएं हैं जिनमें कोई व्यावसायिक तर्क या तरीके लागू नहीं होने चाहिए जो परीक्षण की आवश्यकता होगी ।
2. आम तौर पर आपके मॉडल (एमवीसी पैटर्न का उपयोग करके) बुद्धिमान मॉडल होते हैं, और उनमें बहुत सारे / कुछ तरीके हो सकते हैं जो उस मॉडल के लिए कुछ अलग-अलग ऑपरेशन करते हैं (विशेष रूप से व्यावसायिक तर्क नहीं, यह नियंत्रकों पर होना चाहिए)। हालाँकि, जब आप डेटा ट्रांसफर करते हैं (उदाहरण के लिए , कहीं से एक REST ( GET/ POST/ जो भी) कॉल करते हैं , या SOA, आदि का उपयोग करके वेबबेस का उपभोग करते हैं ...) आप कोड के साथ बड़े आकार की वस्तु को संचारित नहीं करना चाहते हैं जो इसके लिए आवश्यक नहीं है समापन बिंदु, डेटा का उपभोग करेगा, और स्थानांतरण धीमा कर देगा।

Comments

नियंत्रकों में व्यावसायिक तर्क क्यों होना चाहिए?

— एलेक्सियोवे

Answer 6

एमवीसी डेटा ट्रांसफर ऑब्जेक्ट के साथ अक्सर डोमेन मॉडल को मैप करने के लिए सरल वस्तुओं का उपयोग किया जाता है जो अंततः दृश्य द्वारा प्रदर्शित होंगे।

से विकिपीडिया :

डेटा ट्रांसफर ऑब्जेक्ट (DTO), जिसे पहले मूल्य ऑब्जेक्ट या VO के रूप में जाना जाता है, एक डिज़ाइन पैटर्न है जिसका उपयोग सॉफ़्टवेयर एप्लिकेशन सबसिस्टम के बीच डेटा स्थानांतरित करने के लिए किया जाता है। डीटीओ को अक्सर डेटाबेस से डेटा प्राप्त करने के लिए डेटा एक्सेस ऑब्जेक्ट के साथ संयोजन में उपयोग किया जाता है।

Comments

एक मान ऑब्जेक्ट एक DTO नहीं है ।

— कोडरपीसी

Answer 7

डेटा ट्रांसफर ऑब्जेक्ट (DTO) "एक ऐसी वस्तु का वर्णन करता है जो डेटा को प्रक्रियाओं के बीच ले जाती है" (विकिपीडिया) या एक "ऑब्जेक्ट जो डेटा को इनकैप्सुलेट करने के लिए उपयोग किया जाता है, और इसे एक एप्लिकेशन के एक सबसिस्टम से दूसरे में भेजता है" (स्टैक ओवरफ्लो उत्तर)।

Answer 8

DefN

एक डीटीओ एक हार्डकोड डेटा मॉडल है। यह केवल हार्डकोड द्वारा नियंत्रित डेटा रिकॉर्ड मॉडलिंग की समस्या को हल करता है उत्पादन प्रक्रिया , जहां सभी क्षेत्रों को संकलन-समय पर जाना जाता है और इसलिए इसे जोरदार टाइप किए गए गुणों के माध्यम से एक्सेस किया जाता है।

इसके विपरीत, एक गतिशील मॉडल या "प्रॉपर्टी बैग" एक डेटा रिकॉर्ड मॉडलिंग की समस्या को हल करता है जब उत्पादन प्रक्रिया रनटाइम पर बनाई जाती है।

सीवर

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

    class Cvar { ... }

    class Cvar<T> : Cvar
    {
        public T Value { get; set; }
    }

    class MyDTO
    {
        public Cvar<int> X { get; set; }
        public Cvar<int> Y { get; set; }
        public Cvar<string> mutableString { get; set; } // >;)
    }

स्रोत: http://www.powersemantics.com/

डायनेमिक DTO डायनामिक सॉफ़्टवेयर के लिए एक आवश्यक घटक है। एक गतिशील प्रक्रिया को तुरंत करने के लिए, एक संकलक कदम स्क्रिप्ट को संदर्भ गुणों के लिए स्क्रिप्ट में प्रत्येक मशीन को बांधने के लिए है। Cvars को एक संग्रह में जोड़कर एक गतिशील DTO बनाया गया है।

    // a dynamic DTO
    class CvarRegistry : Dictionary<string, Cvar> { }

contentions

नोट: क्योंकि Wix ने "विरोधी पैटर्न" के रूप में मापदंडों को व्यवस्थित करने के लिए डीटीओ के उपयोग को लेबल किया था, इसलिए मैं एक आधिकारिक राय दूंगा।

    return View(model);  // MVC disagrees

मेरी सहयोगी वास्तुकला डिजाइन पैटर्न की जगह लेती है। मेरे वेब लेखों का संदर्भ लें।

पैरामीटर एक स्टैक फ्रेम मशीन का तत्काल नियंत्रण प्रदान करते हैं। यदि आप निरंतर नियंत्रण का उपयोग करते हैं और इसलिए तत्काल नियंत्रण की आवश्यकता नहीं है, तो आपके मॉड्यूल को मापदंडों की आवश्यकता नहीं है। मेरी वास्तुकला में कोई नहीं है। मशीनों की प्रक्रिया विन्यास (विधियाँ) जटिलता जोड़ती है लेकिन मान (प्रदर्शन) भी जब पैरामीटर मान प्रकार होते हैं। हालाँकि, संदर्भ प्रकार के पैरामीटर उपभोक्ता को कैश की कमी के कारण मानों को बंद करने के लिए वैसे भी गायब कर देते हैं - इसलिए, बस संदर्भ गुणों के साथ उपभोक्ता को कॉन्फ़िगर करें। मैकेनिकल इंजीनियरिंग से तथ्य: मापदंडों पर निर्भरता एक प्रकार का पूर्व-निर्धारण है, क्योंकि प्रसंस्करण (घटकों को बनाना) स्वयं बेकार है। अधिक जानकारी के लिए मेरे डब्ल्यू लेख का संदर्भ लें। http://www.powersemantics.com/w.html ।

फाउलर और कंपनी को वितरित आर्किटेक्चर के बाहर डीटीओ के लाभों का एहसास हो सकता है अगर वे कभी किसी अन्य वास्तुकला को जानते थे। प्रोग्रामर केवल वितरित सिस्टम को जानते हैं। एकीकृत सहयोगी प्रणाली (उर्फ उत्पादन उर्फ ​​विनिर्माण) कुछ ऐसी चीजें हैं जिन्हें मुझे अपनी वास्तुकला के रूप में दावा करना था, क्योंकि मैं इस तरह से कोड लिखने वाला पहला व्यक्ति हूं।

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

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