सादा पुराना सीएलआर ऑब्जेक्ट बनाम डेटा ट्रांसफर ऑब्जेक्ट


405

POCO = सादा पुराना CLR (या बेहतर: कक्षा) वस्तु

डीटीओ = डेटा ट्रांसफर ऑब्जेक्ट

इस पोस्ट में एक अंतर है, लेकिन स्पष्ट रूप से अधिकांश ब्लॉग मैंने पढ़ा है कि जिस तरह डीटीओ को परिभाषित किया गया है, उसमें पोको का वर्णन है: डीटीओ सरल डेटा कंटेनर होते हैं जिनका उपयोग किसी एप्लिकेशन की परतों के बीच डेटा स्थानांतरित करने के लिए किया जाता है।

क्या POCO और DTO एक ही बात हैं?


5
"पोको = प्लेन ओल्ड सीएलआर (या बेहतर: क्लास) ऑब्जेक्ट"। इस प्रकार, VB.NET में इस प्रकृति की वस्तुएं POCO भी होंगी, POVOs नहीं।
जे। पोलर

जवाबों:


568

एक POCO OOP के नियमों का पालन करता है। यह (लेकिन नहीं है) राज्य और व्यवहार होना चाहिए । POCO, POJO से आता है, जिसे मार्टिन फाउलर ने लिखा है [ किस्सा यहाँ ]। उन्होंने POJO शब्द का उपयोग फ्रेमवर्क भारी EJB कार्यान्वयन को अस्वीकार करने के लिए इसे और अधिक सेक्सी बनाने के लिए किया। POCO में इसी संदर्भ में POCO का उपयोग किया जाना चाहिए। फ्रेमवर्क को अपने ऑब्जेक्ट के डिज़ाइन को निर्धारित न करने दें।

एक डीटीओ का एकमात्र उद्देश्य राज्य को स्थानांतरित करना है, और कोई व्यवहार नहीं होना चाहिए। इस पैटर्न के उपयोग के एक उदाहरण के लिए एक DTO के मार्टिन फाउलर की व्याख्या देखें ।

यहाँ अंतर है: POCO प्रोग्रामिंग (अच्छे पुराने जमाने की वस्तु उन्मुख प्रोग्रामिंग) के लिए एक दृष्टिकोण का वर्णन करता है , जहाँ डीटीओ एक पैटर्न है जो वस्तुओं का उपयोग करके "डेटा स्थानांतरित" करने के लिए उपयोग किया जाता है।

जब आप DTCO की तरह POCO का इलाज कर सकते हैं, तो आप ऐसा करने पर एनीमिक डोमेन मॉडल बनाने का जोखिम उठाते हैं । इसके अतिरिक्त, संरचना में एक बेमेल है, क्योंकि डीटीओ को डेटा स्थानांतरित करने के लिए डिज़ाइन किया जाना चाहिए, न कि व्यवसाय डोमेन की वास्तविक संरचना का प्रतिनिधित्व करने के लिए। इसका परिणाम यह है कि डीटीओ आपके वास्तविक डोमेन की तुलना में अधिक सपाट होते हैं।

किसी भी उचित जटिलता के एक डोमेन में, आप लगभग हमेशा अलग डोमेन POCO बनाने और डीटीओ में अनुवाद करने से बेहतर हैं। DDD (डोमेन चालित डिज़ाइन) एंटी-करप्शन लेयर ( यहाँ एक और कड़ी है , लेकिन सबसे अच्छी बात किताब खरीदना है ) को परिभाषित करता है , जो एक अच्छी संरचना है जो अलगाव को स्पष्ट करती है।


मुझे पता है कि मैंने मार्टिन फाउलर को यहां संदर्भित किया है, लेकिन उन्होंने POJO शब्द गढ़ा है, और पोएओए पुस्तक लिखी है जो डीटीओ के लिए निश्चित संदर्भ है।
माइकल मीडोज़ 14

मुझे यकीन नहीं है कि अगर डीटीओ के पास व्यवहार नहीं होना चाहिए। मार्टिन फाउलर के आरेख के अनुसार, डीटीओ के व्यवहार हो सकते हैं।
बीटल्स 1692

39
@ बीटल्स 1692, दर्शाए गए तरीके क्रमबद्धता कोड हैं। यह शायद "कोई व्यवहार नहीं" कहने के लिए एक बयान का व्यापक है। कैसे के बारे में "कोई व्यावसायिक तर्क नहीं।" सीरियल कोड, और निम्न स्तर की वस्तु जैसे हैश कोड, समानता, और टोस्टिंग स्वीकार्य होना चाहिए।
माइकल मीडोज

1
@PositiveGuy एक मॉडल डीटीओ से अलग उद्देश्य के लिए कार्य करता है। डीटीओ को एक डोमेन से दूसरे में डेटा ट्रांसफर करने के लिए होना चाहिए (चाहे वे एक ही रनटाइम में अप्रासंगिक हों या नहीं)। एक मॉडल, स्क्रीन, सेवा या डेटा स्रोत जैसे डोमेन के एक पहलू का "प्रतिनिधित्व" करता है। मॉडल में राज्य और व्यवहार शामिल हैं, जो कि वे मॉडलिंग कर रहे हैं, के प्रतिनिधि हैं।
माइकल मीडोज

2
कृपया ध्यान दें कि एनीमिक डोमेन मॉडल आवश्यक रूप से खराब नहीं हैं, खासकर यदि आपका ऐप ज्यादातर सीआरयूडी है। मार्टिन फाउलर की सरलता।
मारियस जमरो

50

यह शायद मेरे लिए योगदान करने के लिए बेमानी है क्योंकि मैंने पहले ही अपने ब्लॉग लेख में अपनी स्थिति बता दी थी, लेकिन उस लेख के अंतिम पैराग्राफ में इस तरह की बातें हैं:

इसलिए, निष्कर्ष में, POCO से प्यार करना सीखें, और सुनिश्चित करें कि आप इसके बारे में कोई गलत जानकारी नहीं फैलाते हैं कि यह DTO जैसी ही है। डीटीओ सरल डेटा कंटेनर होते हैं जिनका उपयोग किसी एप्लिकेशन की परतों के बीच डेटा स्थानांतरित करने के लिए किया जाता है। POCOs एक आवश्यकता के साथ पूर्ण विकसित व्यावसायिक वस्तुएं हैं जो कि वे हठ अज्ञान हैं (कोई तरीका नहीं बचाएं या नहीं)। अंत में, यदि आपने जिमी निल्सन की पुस्तक की अभी तक जांच नहीं की है, तो इसे अपने स्थानीय विश्वविद्यालय के स्टैक से चुनें। C # में इसके उदाहरण हैं और यह एक बेहतरीन रीड है।

BTW, पैट्रिक I ने POCO को एक जीवन शैली लेख के रूप में पढ़ा, और मैं पूरी तरह से सहमत हूं, यह एक शानदार लेख है। यह वास्तव में जिमी निल्सन पुस्तक से एक खंड है जिसकी मैंने सिफारिश की थी। मुझे पता नहीं था कि यह ऑनलाइन उपलब्ध है। उनकी पुस्तक वास्तव में पीओसीओ / डीटीओ / रिपोजिटरी / और अन्य डीडीडी विकास प्रथाओं पर मुझे मिली जानकारी का सबसे अच्छा स्रोत है।


4
ब्लॉग लेख के लिए लिंक: rlacovara.blogspot.com/2009/03/…
Jamie Ide

28

POCO केवल एक ऐसी वस्तु है जो बाहरी ढांचे पर निर्भरता नहीं लेती है। यह PLAIN है।

पीओसीओ में व्यवहार है या नहीं यह सारहीन है।

एक DTO एक डोमेन ऑब्जेक्ट के रूप में POCO हो सकता है (जो आमतौर पर व्यवहार में समृद्ध होगा)।

आमतौर पर डीटीओ धारावाहिक प्रयोजनों के लिए बाहरी रूपरेखाओं (जैसे विशेषताओं) पर निर्भरता लेने की अधिक संभावना रखते हैं क्योंकि आमतौर पर वे एक प्रणाली की सीमा से बाहर निकलते हैं।

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



6

मुझे लगता है कि एक DTO एक POCO हो सकता है। DTO वस्तु के उपयोग के बारे में अधिक है जबकि POCO वस्तु की शैली से अधिक है (वास्तु अवधारणाओं से अलग)।

एक उदाहरण जहां एक POCO DTO से कुछ अलग है, जब आप POCO के अपने डोमेन मॉडल / बिजनेस लॉजिक मॉडल के बारे में बात कर रहे हैं, जो आपके समस्या डोमेन का एक अच्छा OO प्रतिनिधित्व है। आप पूरे आवेदन के दौरान POCO का उपयोग कर सकते हैं, लेकिन इस तरह के ज्ञान लीक के कुछ अवांछनीय दुष्प्रभाव हो सकते हैं। उदाहरण के लिए, डीटीओ सेवा लेयर से उपयोग किया जाता है, जो यूआई के साथ संचार करता है, डीटीओ डेटा का फ्लैट प्रतिनिधित्व करते हैं, और केवल यूआई को डेटा प्रदान करने के लिए उपयोग किया जाता है, और सेवा परत में परिवर्तन संचार करता है। सर्विस लेयर डीटीओ डोमेन ऑब्जेक्ट्स के लिए डीटीओ के दोनों तरीकों को मैप करने के प्रभारी है।

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


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

@ मिशाल मीडोज, हां, लिंक वास्तव में समस्याओं के एक अलग सबसेट के बारे में बात करता है। लेकिन मुझे लगता है कि राज्य को एक सिस्टम सीमा में स्थानांतरित करने के मामले में आपको एक संदर्भ से दूसरे संदर्भ में पीओसीओ को मैप करने के लिए एक अनुवाद सेवा का उपयोग करना चाहिए। या आप एक सिस्टम स्तर पर सीमाओं के बारे में बात कर रहे हैं?
डेवी लैंडमैन

1

डीटीओ के लिए एक प्राथमिक उपयोग का मामला वेब सेवा से डेटा लौटाने में है। इस उदाहरण में, POCO और DTO समतुल्य हैं। POCO में किसी भी व्यवहार को तब हटा दिया जाएगा जब उसे वेब सेवा से लौटाया जाता है, इसलिए यह वास्तव में मायने नहीं रखता कि उसमें व्यवहार है या नहीं।


5
मुझे लगता है कि आपका जवाब गलत बताता है कि थोड़ा क्या होता है। एक वेब सेवा के मामले में, एक वस्तु की उजागर स्थिति के आधार पर एक प्रॉक्सी उत्पन्न होती है। इसका मतलब यह है कि एक DTO को POCO से अलग बनाया गया है, जो कि POCO के समान ही सार्वजनिक राज्य है। यह सूक्ष्म लग सकता है, लेकिन यह महत्वपूर्ण है। कारण यह है कि भले ही प्रॉक्सी मूल के समान हो, यह वास्तव में एक ही वर्ग से निर्मित नहीं है।
माइकल मीडोज

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

5
** शब्दार्थ: वेब सेवाएँ डब्लूएसडीएल का उपयोग कर वस्तु स्थिति को उजागर करती हैं। इन्हीं से प्रमाण उत्पन्न होते हैं। इनमें व्यवहार शामिल नहीं हो सकता। यदि वेब सेवा का उपभोग करते हैं, तो आपके ऑब्जेक्ट और उजागर डोमेन ऑब्जेक्ट के बीच एकमात्र संबंध यह है कि यह एक ही सार्वजनिक स्थिति है जो निरीक्षण के आधार पर बनाई गई है।
माइकल मीडोज

7
@ जॉन, मुझे लगता है कि आप ओवररिएक्ट कर रहे हैं। मैं कह रहा हूँ कि तुम सही हो, लेकिन तुम्हारा शब्द भ्रामक है। "इस मामले में, POCO और DTO बराबर हैं।" शब्दार्थ, यह सच नहीं है। POCOs को डीटीओ और इसके विपरीत के रूप में इस्तेमाल किया जा सकता है, लेकिन इसका मतलब यह नहीं है कि वे समतुल्य हैं ... कार और पिकअप ट्रक के अलावा कोई भी समान नहीं है, भले ही वे दोनों आपको किराने की दुकान तक ले जाने के लिए उपयोग किए जा सकते हैं। उनके पास ओवरलैपिंग फ़ंक्शन है, लेकिन आपको यह जानने के लिए किसी को खोजने के लिए मुश्किल से दबाया जाएगा कि कोई अंतर्दृष्टि F350 के बराबर है, यहां तक ​​कि किराने की यात्रा के संदर्भ में भी।
माइकल मीडोज

3
यह उत्तर बहुत गलत है, एक वेब सेवा एक के लिए पर्याप्त सामान्य नहीं है। सबसे महत्वपूर्ण बात यह एक अच्छी तरह से स्थापित तथ्य है कि डीटीओ एक पीओसीओ नहीं है। डीटीओ एक डेटा कंटेनर है, जबकि पीओसीओ प्रॉपर्टीज के रूप में ऑब्जेक्ट हैं और हठ अज्ञानी हैं (कोई तरीका नहीं बचाएं)।
टॉम स्टिकेल

1

यहाँ सामान्य नियम है: DTO == बुराई और अति-इंजीनियर सॉफ़्टवेयर का संकेतक। POCO == अच्छा। world एंटरप्राइज ’पैटर्न ने जावा ईई दुनिया में बहुत सारे लोगों के दिमाग को नष्ट कर दिया है। कृपया .NET भूमि में गलती न दोहराएं।


7
क्या आप कृपया विस्तार से बता सकते हैं? अनुबंध में कार्यान्वयन और मंच की बारीकियों से बचने के लिए, वेब सेवा से डेटा वापस करते समय डीटीओ की आवश्यकता होती है।
जॉन सॉन्डर्स 14

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

9
मुझे लगता है, @drscroogemcduck, कि शायद आप डीटीओ को नापसंद करते हैं क्योंकि वे एक अंतिम उपाय के बजाय पहले रिसॉर्ट के रूप में उपयोग किए जाते हैं, लेकिन वे स्वाभाविक रूप से बुरे नहीं हैं ... कुख्यात सिंगलटन या फैक्ट्री पैटर्न से अधिक नहीं । क्या बुराई है जो आर्किटेक्ट हैं जो डेवलपर्स के गले को ढंकते हैं जो उन्हें सब कुछ के लिए डीटीओ बनाने के लिए मजबूर करते हैं। वे क्या करते हैं, डेटा स्थानांतरित करने के लिए, डीटीओ (यदि विवेकपूर्ण तरीके से किया जाता है) एकदम सही हैं।
माइकल मीडोज

0

DTO वर्गों का उपयोग विभिन्न स्रोतों से डेटा को क्रमांकित / deserialize करने के लिए किया जाता है। जब आप किसी स्रोत से किसी वस्तु को अलग करना चाहते हैं, तो इससे कोई फर्क नहीं पड़ता है कि वह कौन सा बाहरी स्रोत है: सेवा, फ़ाइल, डेटाबेस आदि। आप केवल उसी के कुछ हिस्से का उपयोग करना चाह सकते हैं, लेकिन आप उस डेटा को डीसर्विलाइज़ करने का एक आसान तरीका चाहते हैं। वस्तु। उसके बाद आप उस डेटा को उस एक्समॉडल पर कॉपी कर लें जिसका आप उपयोग करना चाहते हैं। एक धारावाहिक DTO वस्तुओं को लोड करने के लिए एक सुंदर तकनीक है। क्यों? आपको ऑब्जेक्ट को लोड (डिस्क्रिअलाइज़) करने के लिए केवल एक फ़ंक्शन की आवश्यकता है।


0

टी एल; डॉ:

एक डीटीओ राज्य हस्तांतरण के पैटर्न का वर्णन करता है। एक POCO कुछ भी वर्णन नहीं करता है। यह ओओपी में "ऑब्जेक्ट" कहने का एक और तरीका है। यह POJO (जावा) से आता है, जो मार्टिन फॉलर द्वारा गढ़ा गया है, जो इसे केवल 'ऑब्जेक्ट' के लिए एक कट्टर नाम के रूप में वर्णित करता है क्योंकि 'ऑब्जेक्ट' बहुत सेक्सी नहीं है।

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

एक POCO एक सादा वस्तु है, लेकिन 'सादे' से क्या तात्पर्य है, यह विशेष नहीं है। इसका मतलब यह है कि यह एक सीएलआर ऑब्जेक्ट है, जिसमें कोई निहित पैटर्न नहीं है। एक सामान्य शब्द। इसे किसी अन्य ढांचे के साथ काम करने के लिए नहीं बनाया गया है। [JsonProperty]उदाहरण के लिए, यदि आपके POCO के पास या EF की सभी संपत्तियां हैं, तो यह तर्क है कि यह POCO नहीं है।

तुलना करने के लिए विभिन्न प्रकार के ऑब्जेक्ट पैटर्न के कुछ उदाहरण यहां दिए गए हैं:

  • देखें मॉडल : एक दृश्य के लिए मॉडल डेटा का उपयोग किया जाता है। आमतौर पर बाध्यकारी और सत्यापन की सहायता के लिए डेटा एनोटेशन होते हैं। MVVM में, यह एक नियंत्रक के रूप में भी कार्य करता है। यह डीटीओ से अधिक है
  • मान ऑब्जेक्ट : मानों का प्रतिनिधित्व करने के लिए उपयोग किया जाता है
  • एग्रीगेट रूट : का उपयोग राज्य और आक्रमणकारियों का प्रबंधन करने के लिए किया जाता है
  • हैंडलर : किसी घटना / संदेश का जवाब देने के लिए उपयोग किया जाता है
  • विशेषताएँ : क्रॉस-कटिंग चिंताओं से निपटने के लिए सजावट के रूप में उपयोग किया जाता है
  • सेवा : जटिल कार्यों को करने के लिए उपयोग किया जाता है
  • नियंत्रक : अनुरोधों और प्रतिक्रियाओं के प्रवाह को नियंत्रित करने के लिए उपयोग किया जाता है
  • फैक्ट्री : जब कोई कंस्ट्रक्टर पर्याप्त रूप से अच्छा न हो तो उपयोग के लिए जटिल वस्तुओं को कॉन्फ़िगर और / या इकट्ठा करने के लिए उपयोग किया जाता है। यह भी निर्णय लेने के लिए उपयोग किया जाता है कि किन वस्तुओं को रनटाइम पर बनाने की आवश्यकता है।
  • रिपॉजिटरी / DAO : डेटा तक पहुंचने के लिए उपयोग किया जाता है

ये सभी केवल वस्तुएं हैं, लेकिन ध्यान दें कि उनमें से ज्यादातर आम तौर पर एक पैटर्न से बंधे होते हैं। इसलिए आप उन्हें "ऑब्जेक्ट" कह सकते हैं या आप इसके इरादे के बारे में अधिक विशिष्ट हो सकते हैं और इसे कॉल कर सकते हैं कि यह क्या है। यह भी क्यों हम डिजाइन पैटर्न है; कुछ कार्यों में जटिल अवधारणाओं का वर्णन करने के लिए। DTO एक पैटर्न है। एग्रीगेट रूट एक पैटर्न है, व्यू मॉडल एक पैटर्न है (जैसे एमवीसी और एमवीवीएम)। POCO एक पैटर्न नहीं है।

एक POCO एक पैटर्न का वर्णन नहीं करता है। यह ओओपी में कक्षाओं / वस्तुओं का जिक्र करने का एक अलग तरीका है। इसे एक अमूर्त अवधारणा के रूप में सोचें; वे किसी भी चीज का जिक्र कर सकते हैं। IMO, एकतरफा संबंध है, क्योंकि एक बार जब कोई वस्तु उस बिंदु पर पहुंच जाती है, जहां वह केवल एक उद्देश्य की सफाई से सेवा कर सकता है, तो वह अब POCO नहीं है। उदाहरण के लिए, एक बार जब आप अपनी कक्षा को सजावट के साथ चिह्नित करते हैं, तो कुछ रूपरेखा के साथ काम करने के लिए, यह अब पीओसीओ नहीं है। इसलिए:

  • एक DTO एक POCO है
  • एक POCO एक DTO नहीं है
  • एक दृश्य मॉडल एक POCO है
  • एक POCO एक View Model नहीं है

दोनों के बीच एक अंतर बनाने की बात यह है कि चिंताओं को पार न करने और तंग युग्मन की ओर ले जाने के प्रयास में पैटर्न स्पष्ट और सुसंगत रहें। उदाहरण के लिए यदि आपके पास कोई व्यावसायिक ऑब्जेक्ट है जिसमें स्थिति को म्यूट करने के लिए तरीके हैं, लेकिन SQL सर्वर और JsonProperty को बचाने के लिए EF सजावट के साथ नरक में भी सजाया गया है ताकि इसे एक एपीआई समापन बिंदु पर वापस भेजा जा सके। यह ऑब्जेक्ट बदलने के लिए असहिष्णु होगा, और संभवतः गुणों के वेरिएंट के साथ अटे पड़े होंगे (जैसे UserId, UserPk, UserKey, UserGuid, जहां उनमें से कुछ को डीबी में सहेजे नहीं जाने के लिए चिह्नित किया गया है और अन्य को क्रमबद्ध नहीं किया जाएगा। JSON एपीआई समापन बिंदु पर)।

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


-13

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

मैं चाहता हूं कि बेवकूफ शब्द डीटीओ हमारी शब्दावली से दूर हो जाए।


1
मुझे नहीं पता कि आपको यह विचार कहां से मिला है कि मॉडलों का व्यवहार कभी नहीं होता है। मॉडलिंग व्यवहार के बिना आप CRUD के अलावा कुछ और कैसे मॉडल करते हैं? यहां तक ​​कि ViewModels में कई मामलों में व्यवहार होता है, विशेष रूप से MVVM ऐप्स में। डीटीओ एक उपयोगी शब्द है क्योंकि यह उद्देश्य का सटीक वर्णन करता है; डेटा स्थानांतरित करने के लिए।
गेराल्ड

9
तथ्यात्मक रूप से गलत होने के लिए, और असंवेदनशील रवैये के लिए नीचा दिखाया गया।
joedotnot

बकवास। मॉडल बेवकूफ कंटेनर होना चाहिए। कोई DTO नहीं है, यह एक MS मेड टर्म है। आप डोमेन, सेवाओं और एप्लिकेशन के बीच मॉडल स्थानांतरित करते हैं। अवधि। DTO शब्द की बर्बादी है जिसकी आवश्यकता नहीं है और केवल चीजों को अधिक भ्रमित करता है। मॉडल, मॉडल और अधिक मॉडल यह है। मॉडल में व्यवहार हो सकता है या नहीं भी हो सकता है। देखें मॉडल नहीं होना चाहिए। वह व्यवहार बीएल में होना चाहिए, न कि मॉडल क्लास में।
पॉजिटिव

मैं मानता हूं कि डीटीओ कार्यात्मक रूप से मॉडल हैं। ViewModels का व्यवहार है और वह है जो आप MVVM में बांधते हैं। फिर भी, मैंने एक ऐप लिखा, जहां मेरे मॉडल अधिक बुद्धिमान थे (मूल रूप से वीएम लेकिन मैं उन्हें कॉल नहीं करना चाहता था) और उन्होंने डीटीओ ऑब्जेक्ट को "स्वीकार" किया। इसने मुझे रूपरेखा के साथ अधिक विकल्प रखने की अनुमति दी। इसलिए CRUD (या यहां तक ​​कि EF) से, मैं ऑब्जेक्ट को WCF सेवाओं पर प्रसारित करता हूं और DTO ऑब्जेक्ट प्राप्त करता हूं और इसे एनकैप्सुलेट करता हूं (ऑनप्रॉप चेंज, आदि जोड़कर)। मेरे ViewModels ने आगे इनकैप्सुलेशन किया और "मॉडल" के दो (या एक सूची) को स्वीकार किया हो सकता है। कठोर परिभाषा VMs होगी।
SQLMason

"आप डोमेन, सेवाओं, और एप्लिकेशन के बीच मॉडल स्थानांतरित करते हैं" ऐसा क्यों लगता है कि इस व्यवहार का वर्णन करने के लिए शब्द DTO शब्द की तुलना में अधिक उपयुक्त और उपयुक्त है?
सीएए
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.