DTO = ViewModel?


103

मैं अपने डोमेन ऑब्जेक्ट्स को बनाए रखने के लिए NHibernate का उपयोग कर रहा हूं। चीजों को सरल रखने के लिए मैं अपनी प्रस्तुति परत और मेरी सेवा परत दोनों के रूप में ASP.NET MVC परियोजना का उपयोग कर रहा हूं।

मैं अपने नियंत्रक कक्षाओं से XML में अपनी डोमेन ऑब्जेक्ट वापस करना चाहता हूं। स्टैक ओवरफ्लो पर यहां कुछ पोस्ट पढ़ने के बाद मैं डीटीओ को इकट्ठा करता हूं जो कि जाने का रास्ता है। हालाँकि, मैं ViewModel के बारे में बात करते हुए पोस्ट भी आया हूँ।

मेरा प्रश्न: क्या डेटा ट्रांसफर ऑब्जेक्ट्स और ViewModels एक ही बात है? या एक ViewModel एक DTO का उप पैटर्न है?


9
मुझे लगता है कि यह उल्लेख करना प्रासंगिक है कि ASP.NET MVC में ViewModels WPF (MVVM) में ViewModels के बराबर 100% नहीं हैं, क्योंकि अधिकांश उत्तर MVVM का उल्लेख करते हैं और आप ASP.NET MVC के साथ काम कर रहे हैं।
Matthijs वेसल्स

जवाबों:


105

DTO की विहित परिभाषा बिना किसी व्यवहार के किसी वस्तु का डेटा आकार है।

ViewModels दृश्य के मॉडल हैं। ViewModels आम तौर पर एक या एक से अधिक ऑब्जेक्ट्स (या DTOs) से पूर्ण या आंशिक डेटा होता है, जो कि दृश्य के व्यवहार के लिए विशिष्ट कोई अतिरिक्त सदस्य होता है (दृश्य द्वारा निष्पादित किए जा सकने वाले तरीके, यह देखने के लिए गुण कि कैसे तत्वों को देखें) को टॉगल करें ...)। आप viewmodel को एक दृश्य प्लस व्यवहार के लिए सभी डेटा के रूप में देख सकते हैं। ViewModels व्यावसायिक वस्तुओं या डीटीओ के लिए एक से एक को मैप कर सकता है या नहीं भी कर सकता है।

वैसे, NHibernate अनुमान काम में आते हैं अगर एक निश्चित व्यूमोडल को एक स्थायी ऑब्जेक्ट से डेटा के सबसेट की आवश्यकता होती है।


क्या आप इसे समझा सकते हैं: "डीटीओ बिना किसी व्यवहार के किसी वस्तु का डेटा आकार है"?
रोजोज़ेह S

2
अर्थ ... डीटीओ वर्ग में आमतौर पर केवल गुण होते हैं और व्यावसायिक तर्क आदि के साथ कोई विधियां शामिल नहीं होती हैं ...
डैनियल ऑगर

71

ASP.NET MVC अभ्यास में ViewModel DTO के समान है, हालांकि MVVM पैटर्न में ViewModel DTO से अलग है क्योंकि MVVM में ViewModel का व्यवहार है, लेकिन DTO के पास नहीं है।


4
यह एक अच्छा जवाब है; विवरण पर कम।
फिल

5
Asp.net mvc में ViewModel को DTO जैसा ही क्यों होना चाहिए? इसका कोई अर्थ नही बन रहा है। एक ViewModel एक व्यवहार एक DTO नहीं हो सकता है। यह mvc पर निर्भर नहीं करता है।
एलिजाबेथ

8
ASP.NET MVC ViewModel और MVVM ViewModel के बीच अंतर करने के लिए +1।
रोनाल्ड

5
@ एलिसा - आपके पुराने सवाल का जवाब यह है कि ASP.NET MVC में, मॉडल और व्यू को एक स्टेटलेस तरीके से बदलने के लिए नियंत्रक (नहीं ViewModel) पर कार्रवाई को देखता है। इस वजह से, एक व्यू के आकार का डीटीओ मूल रूप से व्यूमॉडल जैसा ही होता है। हालांकि, एक और क्रमिक सीमा के साथ बड़ी प्रणालियों में, एक DTO फायदेमंद हो सकता है अगर एक ViewModel से अलग हो जो विशेष रूप से View के लिए आकार में हो।
डैनसन

27

डीटीओ! = ViewModel

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


2
इसलिए डीटीओ सिर्फ स्ट्रक्चर्स हो सकता है (या एक ऐसा वर्ग है जो किसी संरचना की क्षमताओं की नकल करना चाहिए)?
मैक्स अलेक्जेंडर

20

डीटीओ - डेटा ट्रांसफर ऑब्जेक्ट बिल्कुल वैसा ही होता है जैसा वह कहता है, डेटा ट्रांसफर करने के लिए कंटेनर। उनके पास कोई व्यवहार नहीं है लेकिन बसने और पाने वालों का एक समूह है। कुछ लोग उन्हें अपरिवर्तनीय बनाते हैं और मौजूदा लोगों को अपडेट करने के बजाय केवल नए बनाते हैं। तार के पार स्थानांतरण की अनुमति देने के लिए उन्हें क्रमबद्ध होना चाहिए।

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

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

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

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

तो फिर से पहले से ही कहा गया डीटीओ! = ViewModel

तथा

DTO और ViewModel के जीवन में अलग-अलग उद्देश्य हैं


13

सबसे पहले, प्रमुख अंतर यह है कि ViewModel में व्यवहार या तरीके हो सकते हैं जो डीटीओ को नहीं होना चाहिए !!!

दूसरा, ASP.NET MVC में एक ViewModel के रूप में डीटीओ का उपयोग करना आपके आवेदन को डीटीओ से कसकर जोड़ देता है और यह डीटीओ का उपयोग करने का बिल्कुल विपरीत उद्देश्य है। यदि आप ऐसा करते हैं, तो आपके डोमेन मॉडल या डीटीओ का उपयोग करने में क्या अंतर है, एक विरोधी पैटर्न प्राप्त करने के लिए अधिक जटिलता?

इसके अलावा ASP.NET में ViewModel सत्यापन के लिए DataAnnotations का उपयोग कर सकता है।

एक ही DTO में अलग-अलग ViewModels मैपिंग हो सकते हैं, और One ViewModel को विभिन्न DTO (हमेशा ऑब्जेक्ट मैपिंग नहीं रचना के साथ) से बनाया जा सकता है। क्योंकि मुझे लगता है कि यह और भी बुरा है अगर आपके पास एक ViewModel है जिसमें एक DTO होता है, तो हमें भी यही समस्या होगी।

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

अंत में यदि आप यह साफ जुदाई करते हैं, तो डेवलपर आसानी से एक साथ काम कर सकते हैं। जो व्यक्ति ViewModels, Views और Controllers डिज़ाइन करता है, उसे सेवा की परत या DTO कार्यान्वयन के बारे में चिंता करने की ज़रूरत नहीं है क्योंकि वह मैपिंग करेगा जब अन्य डेवलपर्स उनके कार्यान्वयन को समाप्त कर देंगे ... वह भरने के लिए Mocking टूल या मैनुअल मॉकिंग का भी उपयोग कर सकते हैं। परीक्षण के लिए डेटा के साथ प्रस्तुति परत।


1
मैंने अभी वीएस 2012 स्थापित किया और वहां एमवीसी 4 सिंगल पेज एप्लीकेशन देखा। नमूना परियोजना में, डीटीओ को वेबएपीआई में नियंत्रक विधियों (या कार्यों) के लिए मापदंडों के रूप में उपयोग किया जाता है। दूसरे शब्दों में, JSON उन तरीकों पर पोस्ट किया गया है और कुछ MVC जादू के साथ, डेटा स्वचालित रूप से डीटीओ में परिवर्तित हो जाता है, विधियों को पारित होने से पहले। क्या आपको लगता है कि इस मामले में डीटीओ का उपयोग करना गलत है। क्या ViewModels को वेब API के साथ उपयोग किया जाना चाहिए? मैं बेहतर समझने के लिए कह रहा हूं, क्योंकि मैं अभी भी इन अवधारणाओं से परिचित नहीं हूं।
जीन-फ्रांकोइस ब्यूचैम्प

साल्ट जीन-फ्रांकोइस ब्यूचैम्प :) ASP.NET MVC किसी वस्तु में url prams को पार्स कर सकता है, उदाहरण के लिए: मान लीजिए कि इस अनुक्रमणिका विधि ajax / index / {jobID} / {ResultsToSkip} / {ResultsToSend} के बजाय "मैपिंग" है। कंट्रोलल इंडेक्स (int jobID, int ResultsToSkip, int ResultsToSend) में मेरे पास इंडेक्स (रिक्वेस्ट) (रिक्वेस्ट एक ऐसी वस्तु है, जो 3 फील्ड जॉब को एनकैप्सुलेट करती है ...) तो अब पैरामैड की बजाय आप अपने एप्लाएंस से उन ऑब्जेक्ट्स के साथ बात कर रहे हैं जो एनकैप्स करते हैं DATA, तो हाँ हम requestDTO कह सकते हैं। उदाहरण के लिए आपको एक अन्य फ़ील्ड को जोड़ना होगा जिसमें आप केवल DTO को बदल सकते हैं, एपीआई इंटरफ़ेस के तरीकों को नहीं।
riadh gomri

9

कुछ सरल विचारों के लिए, मैं अपने मॉडल के रूप में अपने डीटीओ का उपयोग करूंगा, लेकिन जैसे-जैसे दृश्य अधिक जटिल होते जाएंगे, मैं ViewModels बनाऊंगा।

मेरे लिए यह क्विकनेस के बीच एक संतुलन है (डीटीओ का उपयोग करते हुए, क्योंकि मेरे पास पहले से ही 'एम' है) और लचीलापन है (व्यूमॉडल बनाने का मतलब है, चिंताओं को अलग करना)।


2
अच्छा व्यावहारिक जवाब।
साइमन टेवेसी

0

यदि आप DTO को ViewModel के रूप में उपयोग करेंगे, इसका मतलब है कि आप DTO पर उच्च निर्भरता बना रहे हैं क्योंकि किसी कारण से आप DTO बदल रहे हैं तो यह ViewModel पर प्रभाव डाल सकता है।

बेहतर डीटीओ का उपयोग करें और viewmodel में परिवर्तित करें।


-1

हम डीटीओ का उपयोग कर सकते हैंमॉडल वर्ग के समान और हम एक दृश्य में कई मॉडल डेटा / संपत्ति दिखाने / उपयोग करने की आवश्यकता होने पर व्यूमोडल का उपयोग कर सकते हैं। उदाहरण: मैं पहले इकाई फ्रेमवर्क डेटाबेस का उपयोग करके कुछ मॉडल बनाता हूं। इसलिए, अब सभी मॉडल डेटाबेस के आधार पर उत्पन्न होते हैं। और अब हमें डेटा एनोटेशन की आवश्यकता है, उन डेटा एनोटेशन के लिए हम एक फ़ोल्डर नाम डीटीओ बना सकते हैं, इस डीटीओ फ़ोल्डर में, हम उन सभी मॉडलों को सटीक रख सकते हैं जो पहले से ही उत्पन्न करते हैं और संपत्ति के ऊपर डेटा एनोटेशन जोड़ते हैं। फिर हम इस डीटीओ कक्षाओं का उपयोग करके किसी भी ऑपरेशन (कंट्रोलर, व्यूज़ का उपयोग कर सकते हैं) का उपयोग कर सकते हैं। और जब हमें जटिल दृश्य की आवश्यकता होती है, मेरा मतलब है कि जब हमें एक दृश्य में कई वर्गों के डेटा की आवश्यकता होती है तो हम व्यूमोडल का उपयोग कर सकते हैं। Viewmodel के लिए हम एक फ़ोल्डर नाम viewmodel बना सकते हैं, फिर एक कस्टम क्लास बना सकते हैं और उस प्रॉपर्टी को रख सकते हैं जिसकी हमें ज़रूरत है। मैंने खुद को साफ़ करने की कोशिश की। किसी भी सुझाव बहुत सराहना की।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.