MVC और MVVM में क्या अंतर है? [बन्द है]

Question

क्या मानक "मॉडल दृश्य नियंत्रक" पैटर्न और Microsoft के मॉडल / दृश्य / ViewModel पैटर्न के बीच अंतर है?

Comments

ध्यान दें कि जबकि MVVM को Microsoft द्वारा गढ़ा गया था, बहुत सारे गैर-Microsoft डेवलपर्स और परियोजनाओं ने इस पैटर्न को अपनाना शुरू कर दिया है। यह टिप्पणी आपके द्वारा स्पाइट-द-एमएस-हेटर्स विभाग द्वारा लाई गई थी।

— BoltClock

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

— जॉन पीटर्स

उच्च-स्तरीय [डिजाइन पैटर्न] पर इस तरह का उत्कीर्ण प्रश्न। मैं जवाब पर आरेखों के उपयोग का सुझाव देना चाहूंगा।

— रिकार्डो

यहाँ जोएल के लेख का एक संग्रहीत संस्करण है: web.archive.org/web/20150219153055/http://joel.inpointform.net/…

— Tereza Tomcova

MVC विधि के विपरीत, ViewModel एक नियंत्रक नहीं है। इसके बजाय यह एक बाइंडर के रूप में कार्य करता है जो दृश्य और मॉडल के बीच डेटा को बांधता है। जहां एमवीसी प्रारूप विशेष रूप से मॉडल और दृश्य के बीच चिंताओं को अलग करने के लिए बनाया गया है, डेटा-बाइंडिंग के साथ MVVM प्रारूप विशेष रूप से देखने और मॉडल को एक दूसरे के साथ सीधे संवाद करने की अनुमति देने के लिए डिज़ाइन किया गया है। hackernoon.com/…

— blueray

Answer 1

MVC / MVVM / या पसंद नहीं है।

एएसपी.नेट और सिल्वरलाइट / डब्ल्यूपीएफ दोनों विकास में, दो तरीकों से अलग-अलग तरीके से फसल होती है।

ASP.Net के लिए, MVVM को विचारों के भीतर दो-तरफ़ा बाइंड डेटा के लिए उपयोग किया जाता है । यह आम तौर पर एक क्लाइंट-साइड कार्यान्वयन है (उदाहरण के लिए नॉकआउट का उपयोग करके)। दूसरी ओर एमवीसी सर्वर-साइड पर चिंताओं को अलग करने का एक तरीका है ।

सिल्वरलाइट और WPF के लिए, MVVM पैटर्न अधिक शामिल है और दिखाई दे सकता है MVC (या अलग जिम्मेदारियों में सॉफ्टवेयर के आयोजन की अन्य पैटर्न) के लिए एक स्थानापन्न के रूप में कार्य करने के लिए। एक धारणा, जो बार-बार इस पद्धति से बाहर आया, वह था ViewModelबस में नियंत्रक की जगह MVC(जैसे कि तुम सिर्फ स्थानापन्न सकता है VMके लिएC परिवर्णी शब्द में और सभी को माफ किया जाएगा) ...

ViewModel आवश्यक रूप से अलग नियंत्रकों की आवश्यकता को प्रतिस्थापित नहीं करता है ।

समस्या यह है: कि स्वतंत्र रूप से परीक्षण करने योग्य *, और विशेष रूप से पुन: प्रयोज्य होने पर, एक दृश्य-मॉडल को यह पता नहीं है कि कौन सा दृश्य इसे प्रदर्शित कर रहा है, लेकिन अधिक महत्वपूर्ण नहीं है कि इसका डेटा कहां से आ रहा है ।

* नोट: व्यवहार में नियंत्रकों ने ViewModel से अधिकांश तर्क निकाल दिए, जिसके लिए इकाई परीक्षण की आवश्यकता है। वीएम तब एक डंबल कंटेनर बन जाता है जिसके लिए थोड़ा, यदि कोई हो, परीक्षण की आवश्यकता होती है। यह एक अच्छी बात है क्योंकि VM केवल एक पुल है, डिजाइनर और कोडर के बीच, इसलिए इसे सरल रखा जाना चाहिए।

एमवीवीएम में भी, नियंत्रकों में आमतौर पर सभी प्रसंस्करण तर्क होंगे और यह तय करेंगे कि कौन से दृश्य मॉडल का उपयोग करते हुए किस डेटा को प्रदर्शित करना है।

XAML कोड को पीछे से कोड को हटाने के लिए ViewModel पैटर्न का अब तक हमने जो मुख्य लाभ देखा है, उससे XAML संपादन को और अधिक स्वतंत्र कार्य बना दिया गया है । हम अभी भी अपने अनुप्रयोगों के समग्र तर्क को नियंत्रित करने के लिए नियंत्रक (जैसा कि आवश्यकता है, कोई भी इरादा नहीं) बनाते हैं।

हमारे द्वारा अनुसरण किए जाने वाले मूल MVCVM दिशानिर्देश हैं:

• दृश्य डेटा का एक निश्चित आकार प्रदर्शित करते हैं । उन्हें कोई अंदाजा नहीं है कि डेटा कहां से आता है।
• ViewModels डेटा और आदेशों का एक निश्चित आकार रखता है , उन्हें नहीं पता होता है कि डेटा, या कोड कहां से आता है या यह कैसे प्रदर्शित होता है।
• मॉडल वास्तविक डेटा रखते हैं (विभिन्न संदर्भ, स्टोर या अन्य तरीके) रखते हैं
• नियंत्रकों के लिए सुनो, और प्रकाशित, घटनाओं। नियंत्रक तर्क प्रदान करते हैं जो यह नियंत्रित करते हैं कि डेटा क्या देखा जाता है और कहां। नियंत्रणकर्ता ViewModel को कमांड कोड प्रदान करते हैं ताकि ViewModel वास्तव में पुन: प्रयोज्य हो।

हमने यह भी नोट किया कि मूर्तिकला कोड-जीन रूपरेखा MVVM और प्रिज्म के समान एक पैटर्न लागू करता है और यह सभी उपयोग-केस लॉजिक को अलग करने के लिए नियंत्रकों का व्यापक उपयोग भी करता है।

मान लें कि नियंत्रक व्यू-मॉडल द्वारा अप्रचलित नहीं किए जाते हैं।

मैंने इस विषय पर एक ब्लॉग शुरू किया है, जिसे मैं अपनी इच्छानुसार जोड़ूंगा । MVCVM को सामान्य नेविगेशन सिस्टम के साथ संयोजन के साथ समस्याएँ हैं, क्योंकि अधिकांश नेविगेशन सिस्टम केवल Views और VMs का उपयोग करते हैं, लेकिन मैं बाद के लेखों में जाऊंगा।

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

नोट: इस पोस्ट को कई बार संपादित किया गया है, और विशेष रूप से पूछे गए संकीर्ण प्रश्न को लक्षित नहीं किया है, इसलिए मैंने अब इसे कवर करने के लिए पहला भाग अपडेट किया है। बहुत सारी चर्चा, नीचे की टिप्पणियों में, केवल ASP.Net से संबंधित है न कि व्यापक चित्र से। इस पोस्ट का उद्देश्य सिल्वरलाइट, WPF और ASP.Net में MVVM के व्यापक उपयोग को कवर करना था और ViewModels के साथ नियंत्रकों को बदलने से लोगों को हतोत्साहित करने का प्रयास करना था।

Comments

@ टॉमाज़ ज़िलिंस्की: सच है, लेकिन "जहां उनका उपयोग किया जाता है" सवाल नहीं था (या मेरे जवाब का बिंदु)। मेरा कहना यह है कि एमवीवीएम में नियंत्रक अभी भी उपयोगी हैं।

— कोडिंग किया

मैं सहमत हूँ। मेरी टिप्पणी अचानक ज्ञानवर्धन के कारण हुई थी न कि इसलिए कि मैं आपसे असहमत था।

— टॉमाज़ ज़िलिओस्की

हमने विज़ार्ड जैसी UI में "प्रवाह" को नियंत्रित करने के लिए नियंत्रकों का भी उपयोग किया है।

— रिजेबोसच

@ जस्टिन: मैं देख रहा हूँ कि मेरे वाक्य का शब्दांकन थोड़ा अस्पष्ट है। मेरा वास्तव में मतलब है कि सभी घटकों के लिए यूनिट-परीक्षण अधिक आसानी से समर्थित है, विशेष रूप से केवल ViewModels के परीक्षण में सुधार नहीं है (जो कि आप बताते हैं कि वास्तव में MVCVM में उतना नहीं है ... जो आप चाहते हैं)। नियंत्रकों का वास्तविक लाभ यह है कि आप वास्तव में ViewModel (जहां लोग नियंत्रक तर्क को बचाते हैं) से परीक्षण के लिए अधिकांश आवश्यकताओं को हटा रहे हैं और इसे डाल रहे हैं जहां इसका परीक्षण किया जा सकता है (मुख्य रूप से नियंत्रक और मॉडल)। पुन: उपयोग की टिप्पणी उस वाक्य में VMs के लिए विशिष्ट है। मैंने इसे संपादित किया है।

— कोडिंग किया

@TomaszZielinski M (MVVM) C

— मोहम्मद इमाद

Answer 2

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

जैसे-जैसे वे 2000 के दशक के मध्य में जटिलता में बढ़ते गए, MVC सॉफ़्टवेयर डिज़ाइन पैटर्न - जिसे पहली बार 1970 के दशक में वर्णित किया गया - वेब अनुप्रयोगों पर लागू किया जाने लगा। डेटाबेस, एचटीएमएल पेज और कोड इनबेटन सोचें। आइए MVC पर आने के लिए इसे थोड़ा परिष्कृत करें: »डेटाबेस« के लिए, आइए डेटाबेस प्लस इंटरफ़ेस कोड मान लें। »HTML पेजों के लिए, मान लें कि HTML टेम्पलेट प्लस टेम्प्लेट प्रोसेसिंग कोड है। »कोड inbetween« के लिए, मान लेते हैं कि कोड मैपिंग उपयोगकर्ता क्लिक टू एक्शन, संभवतः डेटाबेस को प्रभावित कर रहा है, निश्चित रूप से एक और दृश्य प्रदर्शित हो सकता है। यह कम से कम, इस तुलना के उद्देश्य के लिए है।

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

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

और यह समृद्ध डेस्कटॉप तरीका संभवत: वह है जहां दूसरा संक्षिप्त नाम एमवीवीएम है। सी। के चूक से अक्षरों से मूर्ख मत बनो, नियंत्रक अभी भी हैं। उन्हें होना चाहिए। कुछ भी नहीं निकलता है। हम सिर्फ एक चीज जोड़ते हैं: स्थिति, क्लाइंट पर कैश की गई डेटा (और इसके साथ ही उस डेटा को संभालने के लिए बुद्धिमत्ता)। वह डेटा, अनिवार्य रूप से क्लाइंट पर एक कैश है, जिसे अब »ViewModel« कहा जाता है। यह वही है जो समृद्ध अन्तरक्रियाशीलता की अनुमति देता है। और बस।

• MVC = मॉडल, नियंत्रक, दृश्य = अनिवार्य रूप से एक तरफ़ा संचार = खराब अन्तरक्रियाशीलता
• MVVM = मॉडल, कंट्रोलर, कैश, व्यू = टू-वे कम्युनिकेशन = रिच इंटरएक्टिविटी

हम यह देख सकते हैं कि फ्लैश, सिल्वरलाइट, और - सबसे महत्वपूर्ण - जावास्क्रिप्ट के साथ, वेब ने एमवीवीएम को गले लगा लिया है। ब्राउज़रों को अब वैध रूप से पतले ग्राहक नहीं कहा जा सकता है। उनकी प्रोग्रामबिलिटी देखिए। उनकी स्मृति खपत को देखें। आधुनिक वेब पेजों पर सभी जावास्क्रिप्ट अन्तरक्रियाशीलता को देखें।

व्यक्तिगत रूप से, मुझे यह सिद्धांत लगता है और व्यवसाय को समझने में आसान लगता है कि यह ठोस वास्तविकता में क्या है। अमूर्त अवधारणाएं उपयोगी हैं, खासकर जब ठोस पदार्थ पर प्रदर्शन किया जाता है, तो समझ पूर्ण चक्र में आ सकती है।

 

Comments

MVC वेब पर उत्पन्न नहीं हुआ था। ट्राएगवे रेन्सकग ने 1970 के दशक में MVC को स्मॉलटाक -76 में पेश किया।

— एरियलडो मार्टिनी 21

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

— डैन बेचर

एरियलो: धन्यवाद, मैं स्मॉलटाक -76 के बारे में नहीं जानता था। (तब अन्य खिलौनों के साथ खेला जाता है। :) एक तरफ मजाक करता है, यह दिलचस्प है कि इनमें से कुछ अवधारणाएं कितनी पुरानी हैं। - @, मैंने जो लिखा है वह है: "[[एमवीसी] [वेब] से पहले हो सकता है, लेकिन वेब इस तरह से वेब डेवलपर्स के बड़े पैमाने पर लोकप्रिय हो गया है।" मुझे अब भी लगता है कि यह सही है। मेरे पास इसके लिए कोई उद्धरण नहीं है, लेकिन तब मुझे नहीं लगता कि मुझे एक की आवश्यकता है, क्योंकि पिछले दशक की शुरुआत में एक वेब डेवलपर के रूप में शुरू होने पर एमवीसी बड़े पैमाने पर लोकप्रिय होना मेरे व्यक्तिगत अनुभव का हिस्सा है। Apache Struts को MVC के लिए बहुत सारी सेम के साथ फिर से प्रचलित किया गया था।

— लुमी

MVC "अनिवार्य रूप से एक-तरफ़ा संचार" नहीं है क्योंकि ब्राउज़र हर समय हो जाता है और पोस्ट जारी करता है। दोनों हो जाता है और पोस्ट क्वेरी स्ट्रिंग में पाया फ़ील्ड मान बदल सकते हैं। यह ब्राउज़रों को नियंत्रक को जानकारी भेजने का पर्याप्त अवसर देता है। MVC को HTTP 1.0 के ऊपर बनाया गया था जिसमें हमेशा दो तरह से संचार होता था।

— जॉन पीटर्स

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

— gcdev

Answer 3

MVVM मॉडल-व्यू ViewModel MVC, मॉडल-व्यू नियंत्रक के समान है

नियंत्रक को एक ViewModel से बदल दिया जाता है । ViewModel UI परत के नीचे बैठता है। ViewModel उन डेटा और कमांड ऑब्जेक्ट को उजागर करता है, जिन्हें व्यू की आवश्यकता होती है। आप इसे एक कंटेनर ऑब्जेक्ट के रूप में सोच सकते हैं जो कि इसके डेटा और कार्यों को देखने के लिए जाता है। ViewModel मॉडल से अपना डेटा खींचता है।

रसेल ईस्ट एक ब्लॉग पर विस्तार से चर्चा करता है कि MVVM MVC से अलग क्यों है

Comments

वाक्य "नियंत्रक को एक दृश्य मॉडल के साथ बदल दिया जाता है" सही नहीं है। MVVM में नियंत्रक की भूमिका क्या है डेटाबाइंडिंग (या यदि आप इसका उपयोग करते हैं तो कन्वेंशन द्वारा बाइंडिंग)।

— दानीसी

WPV के दो तरह से डेटा बाइंडिंग का उपयोग करने पर MVVM केवल समझ में आएगा। अन्यथा MVC / MVP आदि पर्याप्त होगा।

— जेफ

@ डानीसी: जोश स्मिथ:If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. …

— sll

@OmShankar 11 वीं खुद से नहीं है। कुल 10 लोग हैं, और 12 कुल राय हैं। कहावत का तात्पर्य यह है कि इन प्रतिमानों की परिभाषाएँ व्याख्या के लिए इतनी खुली हैं कि कम से कम दो लोग एक से अधिक राय रखने के लिए पर्याप्त भ्रमित होंगे।

— डैन बेचर

@DaniCE खैर यह वास्तव में WPF के डेटा बाइंडिंग का बिंदु है, और Microsoft ने MVVM का आविष्कार किया है, जिसमें कोई भी नियंत्रक को पूरी तरह से बायपास कर सकता है, (यह दावा करते हुए कि "गलत तरीके से नियंत्रक को प्रतिस्थापित किया जा रहा है" सिर्फ गलत है। पर्दे के पीछे एक नियंत्रक, मूल रूप से एक बयान का दावा करने की तरह है "उच्च स्तरीय भाषा क्रिप्टिक मशीन कोड के उपयोग को अधिक पठनीय के साथ बदल देती है" गलत होने के लिए क्योंकि पर्दे के पीछे मशीन भाषा अभी भी उपयोग की जा रही है ...)

— योएल हलब जूल

Answer 4

एक बात के लिए, MVVM MVC पैटर्न की प्रगति है जो डिस्प्ले को संभालने के लिए XAML का उपयोग करता है। यह लेख दोनों के कुछ पहलुओं को रेखांकित करता है।

मॉडल / दृश्य / ViewModel वास्तुकला का मुख्य जोर ऐसा लगता है कि डेटा ("मॉडल") के शीर्ष पर, गैर-दृश्य घटकों की एक और परत है ("ViewModel") जो डेटा की अवधारणाओं को बहुत बारीकी से मैप करता है डेटा के दृश्य की अवधारणाएं ("दृश्य")। यह ViewModel है कि दृश्य सीधे मॉडल को बांधता है, नहीं।

Comments

मुझे लगता है कि आपने जो पैराग्राफ उद्धृत किया है, वह अच्छी तरह से IMHO है। ViewModel का एक पहलू यह है कि यह दृश्य के लिए मॉडल का एक चपटा / परिवर्तित संस्करण है। कई अन्य एमवी * पैटर्न वास्तविक मॉडल के खिलाफ बांधते हैं ।

— डैनियल ऑगर

"कई अन्य एमवी * पैटर्न वास्तविक मॉडल को फिर से बांधते हैं"? वास्तव में? मुझे लगा कि यह दृश्य हमेशा एमवीसी में नियंत्रक को बांधने वाला था, कोई फर्क नहीं पड़ता।

— प्लेगहैमर

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

— टोमाज़ ज़िलिओस्की

@ नोक्टर्न क्या डेनियल ने कहा कि आधिकारिक तौर पर सभी एमवी * को एक अलग वीएम का उपयोग करना चाहिए, जबकि कई डेवलपर्स इसे अनदेखा करते हैं, और वास्तविक मॉडल को पारित करते हैं, और वास्तव में एमवीसी के उदाहरण के लिए विनिर्देशों में कुछ भी इसे अस्वीकार नहीं करता है, हालांकि एमवीवीएम में एक एक वीएम को मॉडल और दृश्य के बीच के संक्रमण के लिए जिम्मेदार होना चाहिए

— योएल हलब जूल

मैं इसे इस तरह कहूंगा: मॉडल DB स्कीमा के लिए कोठरी बात है। जब कोई क्वेरी चलाई जाती है तो वह मॉडल लेयर में डेटा को मजबूत प्रकारों में प्रोजेक्ट कर सकती है। व्यूमॉडल मॉडल ऑब्जेक्ट्स सहित चीजों का संग्रह है, लेकिन डेटा के संबंध में दृश्य स्थिति को पकड़ और कर सकता है। नियंत्रक केवल दृश्य और दृश्य के बीच एक ट्रैफ़िक पुलिस है और निश्चित रूप से दृश्य केवल दृश्य राज्यों से संबंधित है।

— जॉन पीटर्स

Answer 5

Microsoft ने यहां विंडोज वातावरण में MVVM पैटर्न का स्पष्टीकरण दिया ।

यहाँ एक महत्वपूर्ण खंड है:

मॉडल-व्यू-व्यूमॉडल डिजाइन पैटर्न में, एक ऐप तीन सामान्य घटकों से बना है।

• मॉडल : यह उस डेटा मॉडल का प्रतिनिधित्व करता है जो आपका ऐप उपभोग करता है। उदाहरण के लिए, एक तस्वीर साझाकरण ऐप में, यह परत एक उपकरण पर उपलब्ध चित्रों के सेट का प्रतिनिधित्व कर सकती है और एपीआई चित्र पुस्तकालय में पढ़ने और लिखने के लिए उपयोग किया जाता है।

• दृश्य : एक ऐप आमतौर पर UI के कई पृष्ठों से बना होता है। उपयोगकर्ता को दिखाया गया प्रत्येक पृष्ठ MVVM शब्दावली में एक दृश्य है। दृश्य XAML कोड है जो उपयोगकर्ता को देखने और शैली को परिभाषित करने के लिए उपयोग किया जाता है। मॉडल से डेटा उपयोगकर्ता को प्रदर्शित किया जाता है, और ऐप की वर्तमान स्थिति के आधार पर यूआई को यह डेटा खिलाने के लिए ViewModel का काम है। उदाहरण के लिए, एक तस्वीर साझाकरण ऐप में, विचार यूआई होंगे जो उपयोगकर्ता को डिवाइस पर एल्बम की सूची, एक एल्बम में चित्र और शायद एक और है जो उपयोगकर्ता को एक विशेष तस्वीर दिखाता है।

• ViewModel : ViewModel ऐप के डेटा मॉडल, या बस मॉडल को UI, या विचारों से जोड़ता है। इसमें वह तर्क होता है जिसके साथ मॉडल से डेटा का प्रबंधन किया जाता है और डेटा को गुणों के एक सेट के रूप में उजागर करता है जिससे XAML UI, या दृश्य, बाँध सकता है। उदाहरण के लिए, एक तस्वीर साझाकरण ऐप में, ViewModel एल्बमों की एक सूची को उजागर करेगा, और प्रत्येक एल्बम के लिए चित्रों की एक सूची को उजागर करेगा। यूआई अज्ञेयवादी है कि चित्र कहाँ से आते हैं और उन्हें कैसे पुनर्प्राप्त किया जाता है। यह बस ViewModel द्वारा उजागर चित्रों का एक सेट जानता है और उन्हें उपयोगकर्ता को दिखाता है।

Comments

ध्यान दें कि आलेख संदर्भित करते समय Microsoft Stack - विशेष रूप से Windows Phone - और XAML के साथ विकास पर लागू होता है, यह होना जरूरी नहीं है।

— रिचर्ड नालेजिंस्की

यह उत्तर "MVVM" नाम के साथ समस्या पर प्रकाश डालता है - यह "VVMM" या "MVMV" होना चाहिए - MV-VM ने रिश्तों को पूरी तरह से गलत तरीके से घेर लिया है!

— एथमन

Answer 6

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

यदि मैं कबाड़ से भरा नहीं हूं, तो मुझे आश्चर्य है कि किसी ने भी हाइब्रिड नहीं बनाया है, जहां आपका वीएम केवल एम प्रॉक्सी है, और सी सभी कार्यक्षमता प्रदान करता है।

Comments

+1। यह शब्द सही है जो मुझे लगता है। लेकिन हाइब्रिड M-MProxy-VC बनाने के बारे में क्या यह बहुत अलग नहीं है? मुझे लगता है कि यह एमवीसी का उपयोग करने के लिए पर्याप्त होगा जबकि एम बाइंडिंग के पूर्ण समर्थन के साथ एक मॉडल है। ;)

— ktutnik

+1। जैसा कि मैंने ऊपर टिप्पणी की है, मुझे लगता है कि एमवीसी का उपयोग संपूर्ण (वेब) एप्लिकेशन को आर्किटेक्ट करने के लिए किया जाता है, जबकि एमवीवी का उपयोग एमवीसी के व्यू घटक के अंदर किया जाता है।

— टॉमाज़ ज़िलिओस्की

@ktutnik: मॉडल आमतौर पर सर्वर पर बैठता है, जबकि ViewModel क्लाइंट पर रहता है। तो यह HTML के लिए सर्वर-साइड मॉडल से सीधे जुड़ने के लिए कोई संभव नहीं है। इसलिए हमें ModelView की जरूरत है जो AJAX / JSON का उपयोग करके मॉडल से निकाले गए डेटा के एक स्थानीय, बिना सहेजे हुए कार्य सेट के रूप में कार्य करता है।

— टॉमस ज़ीलिस्की 23

दृश्य वास्तव में मॉडल डेटा को "पढ़ता है" क्योंकि यह पहले से ही नियंत्रक द्वारा रखा गया है। मैं इसे नियंत्रक द्वारा "डेटा इंजेक्शन" के रूप में संदर्भित करना पसंद करता हूं क्योंकि यह वास्तव में नियंत्रक है जो प्रभारी है। सभी दृश्य मेरे मन में रेंडर और आग की घटनाओं में करता है।

— जॉन पीटर्स

मैं MVVM की व्याख्या से असहमत हूं। एक ViewModel में View के बारे में कोई विचार नहीं है या एक View कैसा दिखाई देगा या यह कैसे प्रतिक्रिया देगा और इसी तरह एक मॉडल में एक ViewModel का कोई विचार नहीं है। वास्तव में, एक दृश्य को एक मॉडल के बारे में भी नहीं जानना चाहिए, बस एक ViewModel। मॉडल को डेटा और एप्लिकेशन स्थिति का प्रतिनिधित्व करना चाहिए, ViewModel को UI सक्षम डेटा में राज्य का अनुवाद करना चाहिए (मैं इस बिंदु पर सभी प्राथमिकताओं की सिफारिश करता हूं) और ViewModels अनुवाद पर एक प्रतिक्रिया होनी चाहिए। डेटा अक्सर समान होगा, लेकिन इसे अभी भी लपेटा जाना चाहिए और एक ViewModel के माध्यम से फिर से वितरित किया जाना चाहिए और कोई नियंत्रक मौजूद नहीं है।

— माइकल पिकेट द्वितीय

Answer 7

सरल अंतर: (याकोव के कसेरा एंगुलरजेएस पाठ्यक्रम से प्रेरित)

MVC (मॉडल व्यू कंट्रोलर)

1. मॉडल: मॉडल में डेटा की जानकारी होती है। नियंत्रक और दृश्य को कॉल या उपयोग नहीं करता है। डेटा का प्रतिनिधित्व करने के लिए व्यावसायिक तर्क और तरीके शामिल हैं। कुछ डेटा, किसी रूप में, दृश्य में प्रदर्शित किए जा सकते हैं। इसमें कुछ स्रोत से डेटा पुनर्प्राप्त करने के लिए तर्क भी हो सकते हैं।
2. नियंत्रक: दृश्य और मॉडल के बीच संबंध के रूप में कार्य करता है। कॉल नियंत्रक और नियंत्रक मॉडल कॉल को देखें। यह मूल रूप से मॉडल और / या दृश्य को उपयुक्त के रूप में बदलने के लिए सूचित करता है।
3. देखें: UI भाग के साथ सौदे उपयोगकर्ता के साथ बातचीत करता है।

MVVM (मॉडल देखें मॉडल देखें)

दृश्यमॉडल :

1. यह दृश्य की स्थिति का प्रतिनिधित्व है।
2. यह उस डेटा को रखता है जो दृश्य में प्रदर्शित होता है।
3. घटनाओं, उर्फ ​​प्रस्तुति तर्क को देखने के लिए प्रतिक्रिया करता है।
4. व्यापार तर्क प्रसंस्करण के लिए अन्य कार्य करता है।
5. कभी भी किसी भी चीज़ को प्रदर्शित करने के लिए सीधे नहीं पूछता है।

Answer 8

एमवीसी एक नियंत्रित वातावरण है और एमवीवीएम एक प्रतिक्रियाशील वातावरण है।

एक नियंत्रित वातावरण में आपके पास कम कोड और तर्क का एक सामान्य स्रोत होना चाहिए; जो हमेशा नियंत्रक के भीतर रहना चाहिए। तथापि; वेब दुनिया में एमवीसी आसानी से व्यू लॉजिक लॉजिक और डायनेमिक लॉजिक में विभाजित हो जाता है। सृजन सर्वर पर रहता है और क्लाइंट पर गतिशील जीवन। आप इसे ASP.NET MVC के साथ AngularJS के साथ संयुक्त रूप से देखते हैं, जबकि सर्वर एक दृश्य बनाएगा और एक मॉडल में पास होगा और इसे क्लाइंट को भेजेगा। क्लाइंट तब व्यू के साथ बातचीत करेगा जिस स्थिति में AngularJS एक स्थानीय नियंत्रक के रूप में कदम रखता है। एक बार मॉडल प्रस्तुत करने के बाद या एक नया मॉडल सर्वर नियंत्रक को वापस सौंप दिया जाता है और संभाला जाता है। (इस प्रकार यह सिलसिला जारी है और सॉकेट या AJAX आदि के साथ काम करते समय इस हैंडलिंग के कई अन्य अनुवाद हैं लेकिन सभी वास्तुकला समान हैं।)

MVVM एक प्रतिक्रियाशील वातावरण है जिसका अर्थ है कि आप आमतौर पर कोड (जैसे ट्रिगर) लिखते हैं जो किसी घटना के आधार पर सक्रिय होगा। XAML में, जहां MVVM संपन्न होता है, यह बिल्ट इन डाटाइबिंग फ्रेमवर्क BUT के साथ आसानी से किया जाता है जैसा कि यह उल्लेख किया गया है कि यह किसी भी सिस्टम में किसी भी प्रोग्रामिंग भाषा के साथ किसी भी सिस्टम पर काम करेगा। यह एमएस विशिष्ट नहीं है। ViewModel आग (आमतौर पर एक संपत्ति बदली हुई घटना) और आप जो भी ट्रिगर बनाते हैं, उसके आधार पर दृश्य इस पर प्रतिक्रिया करता है। यह तकनीकी प्राप्त कर सकता है, लेकिन नीचे की रेखा है व्यू स्टेट रहित और बिना तर्क के है। यह केवल मूल्यों के आधार पर स्थिति को बदलता है। इसके अलावा, ViewModels बहुत कम तर्क के साथ स्टेटलेस हैं, और मॉडल अनिवार्य रूप से शून्य तर्क वाले राज्य हैं क्योंकि उन्हें केवल राज्य बनाए रखना चाहिए। मैं इसे एप्लिकेशन स्टेट (मॉडल), स्टेट ट्रांसलेटर (ViewModel), और फिर विजुअल स्टेट / इंटरैक्शन (व्यू) के रूप में वर्णित करता हूं।

MVC डेस्कटॉप या क्लाइंट साइड एप्लिकेशन में आपके पास एक मॉडल होना चाहिए, और मॉडल को नियंत्रक द्वारा उपयोग किया जाना चाहिए। मॉडल के आधार पर नियंत्रक दृश्य को संशोधित करेगा। व्यूज़ आमतौर पर कंट्रोलर्स के साथ इंटरफेर्स से जुड़े होते हैं ताकि कंट्रोलर कई तरह के व्यूज़ के साथ काम कर सके। ASP.NET में MVC के लिए तर्क सर्वर पर थोड़ा पीछे है क्योंकि नियंत्रक मॉडल का प्रबंधन करता है और मॉडल को चयनित दृश्य में भेजता है। तब दृश्य मॉडल के आधार पर डेटा से भरा होता है और इसका अपना तर्क होता है (आमतौर पर एक और MVC जैसे कि AngularJS के साथ किया जाता है)। लोग बहस करेंगे और इसे आवेदन एमवीसी के साथ भ्रमित करेंगे और दोनों को करने की कोशिश करेंगे जिस बिंदु पर परियोजना को बनाए रखना अंततः एक आपदा बन जाएगा। हमेशा MVC का उपयोग करते समय तर्क और नियंत्रण को एक स्थान पर रखा जाता है। नियंत्रक या मॉडल डेटा को समायोजित करने के लिए देखें (या वेब के लिए जेएस के माध्यम से देखें) के पीछे कोड में देखें तर्क न लिखें। नियंत्रक को दृश्य बदलने दें। केवल तर्क जो एक दृश्य में रहना चाहिए, वह वह है जिसे वह उपयोग किए जाने वाले इंटरफ़ेस के माध्यम से बनाने और चलाने के लिए लेता है। इसका एक उदाहरण एक उपयोगकर्ता नाम और पासवर्ड प्रस्तुत कर रहा है। चाहे डेस्कटॉप या वेब पेज (क्लाइंट पर) नियंत्रक को सबमिट प्रक्रिया को संभालना चाहिए, जब भी दृश्य सबमिट कार्रवाई को आग लगाता है। अगर सही तरीके से किया जाए तो आप हमेशा एमवीसी वेब या स्थानीय ऐप के आसपास अपना रास्ता आसानी से पा सकते हैं। चाहे डेस्कटॉप या वेब पेज (क्लाइंट पर) नियंत्रक को सबमिट प्रक्रिया को संभालना चाहिए, जब भी दृश्य सबमिट कार्रवाई को आग लगाता है। अगर सही तरीके से किया जाए तो आप हमेशा एमवीसी वेब या स्थानीय ऐप के आसपास अपना रास्ता आसानी से पा सकते हैं। चाहे डेस्कटॉप या वेब पेज (क्लाइंट पर) नियंत्रक को सबमिट प्रक्रिया को संभालना चाहिए, जब भी दृश्य सबमिट कार्रवाई को आग लगाता है। अगर सही तरीके से किया जाए तो आप हमेशा एमवीसी वेब या स्थानीय ऐप के आसपास अपना रास्ता आसानी से पा सकते हैं।

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

यहाँ एक छोटा सा उदाहरण है: मान लें कि आप बटन प्रेस पर एक मेनू स्लाइड चाहते हैं। एमवीसी में आपके इंटरफ़ेस में मेन्यूप्रेस्ड एक्शन होगा। जब आप मेनू बटन पर क्लिक करेंगे तो कंट्रोलर को पता चलेगा और फिर View को मेनू में स्लाइड करने के लिए अन्य इंटरफ़ेस विधि जैसे SlideMenuIn पर आधारित बताएं। किस कारण से एक गोल यात्रा? नियंत्रक का निर्णय करें कि आप ऐसा नहीं कर सकते या इसके बजाय कुछ और करना चाहते हैं। जब तक कि नियंत्रक ऐसा न कहे, तब तक व्यू के साथ कंट्रोलर को व्यू का प्रभारी होना चाहिए। तथापि; एमवीवीएम में एनीमेशन में स्लाइड मेनू को सामान्य और सामान्य रूप से बनाया जाना चाहिए और इसके बजाय इसे स्लाइड करने के लिए कहा जाएगा जो कुछ मूल्य के आधार पर ऐसा करेगा। तो यह ViewModel को सुनता है और जब ViewModel कहता है, IsMenuActive = true (या फिर) उसके लिए एनीमेशन होता है। अभी, इसके साथ ही मैंने कहा कि मैं एक और बिंदु बनाना चाहता हूं और कृपया ध्यान दें। IsMenuActive शायद BAD MVVM या ViewModel डिज़ाइन है। ViewModel को डिज़ाइन करते समय आपको कभी भी यह नहीं समझना चाहिए कि व्यू में कोई भी विशेषताएँ होंगी और बस अनुवादित मॉडल स्थिति को पास करना होगा। इस तरह यदि आप मेनू को हटाने के लिए अपना दृश्य बदलने का निर्णय लेते हैं और डेटा / विकल्प को दूसरे तरीके से दिखाते हैं, तो ViewModel परवाह नहीं करता है। तो आप मेनू का प्रबंधन कैसे करेंगे? जब डेटा समझ में आता है कि कैसे। तो, ऐसा करने का एक तरीका मेनू को विकल्पों की एक सूची देना है (शायद आंतरिक ViewModels की एक सरणी)। यदि उस सूची में डेटा है, तो मेनू ट्रिगर के माध्यम से खोलना जानता है, यदि नहीं तो वह ट्रिगर के माध्यम से छिपाना जानता है। आपके पास मेनू के लिए डेटा है या ViewModel में नहीं है। ViewModel में उस डेटा को दिखाने / छिपाने का निर्णय न करें .. बस मॉडल की स्थिति का अनुवाद करें। इस तरह से व्यू पूरी तरह प्रतिक्रियाशील और सामान्य है और कई अलग-अलग स्थितियों में इसका इस्तेमाल किया जा सकता है।

यह सब संभवत: पूरी तरह से समझ में नहीं आता है यदि आप पहले से ही प्रत्येक की वास्तुकला से कम से कम थोड़ा परिचित नहीं हैं और इसे सीखना बहुत ही भ्रमित कर सकता है क्योंकि आपको नेट पर बहुत सारी जानकारी मिल जाएगी।

तो ... यह अधिकार पाने के लिए ध्यान रखने वाली बातें। अपने एप्लिकेशन को डिज़ाइन करने के तरीके का फैसला करें और इसे STICK TO IT करें।

यदि आप एमवीसी करते हैं, जो महान है, तो सुनिश्चित करें कि आप नियंत्रक प्रबंधनीय हैं और अपने दृश्य के पूर्ण नियंत्रण में हैं। यदि आपके पास एक बड़ा दृश्य है, तो उस नियंत्रण को जोड़ने पर विचार करें जिसमें विभिन्न नियंत्रक हैं। बस उन नियंत्रकों को अलग-अलग नियंत्रकों तक नहीं ले जाना चाहिए। बनाए रखने के लिए बहुत निराशा होती है। एक पल लें और चीजों को अलग-अलग तरीके से डिजाइन करें जो अलग-अलग घटकों के रूप में काम करेंगे ... और हमेशा नियंत्रक को मॉडल को प्रतिबद्धता या भंडारण को बनाए रखने के लिए कहें। MVC के लिए आदर्श निर्भरता सेटअप देखें Model नियंत्रक → मॉडल या ASP.NET के साथ (मुझे आरंभ न करें) मॉडल → नियंत्रक ↔ नियंत्रक → मॉडल (जहां मॉडल एक ही हो सकता है या नियंत्रक से देखने के लिए एक पूरी तरह से अलग मॉडल हो सकता है)... बेशक इस बिंदु पर नियंत्रक को केवल देखने की जरूरत है, ज्यादातर समापन बिंदु संदर्भ के लिए यह जानना है कि एक मॉडल को वापस कहां करना है।

यदि आप MVVM करते हैं, तो मैं आपकी दयालु आत्मा को आशीर्वाद देता हूं, लेकिन इसे करने के लिए समय निकालें! एक के लिए इंटरफेस का उपयोग न करें। मानों के आधार पर यह देखने का निर्णय लें कि यह कैसा दिखने वाला है। मॉक डेटा के साथ दृश्य के साथ खेलो। यदि आपके पास एक दृश्य है जो आपको एक मेनू दिखा रहा है (उदाहरण के अनुसार) भले ही आप इसे उस समय नहीं चाहते थे तो GOOD। आप देख रहे हैं कि यह मानों के आधार पर काम कर रहा है और इसे प्रतिक्रिया देनी चाहिए। बस यह सुनिश्चित करने के लिए अपने ट्रिगर में कुछ और आवश्यकताएं जोड़ें कि जब ViewModel किसी विशेष अनुवादित स्थिति में हो या ViewModel को इस स्थिति को खाली करने के लिए आदेश दें। अपने ViewModel में इसे आंतरिक तर्क के साथ न निकालें, जैसे कि आप वहां से तय कर रहे हैं कि क्या इसे देखना चाहिए या नहीं। याद रखें कि आप यह नहीं मान सकते हैं कि ViewModel में कोई मेनू है या नहीं। और अंत में, मॉडल को बस आपको बदलने और सबसे अधिक संभावना स्टोर स्थिति की अनुमति देनी चाहिए। यह वह जगह है जहाँ सत्यापन और सभी घटित होंगे; उदाहरण के लिए, यदि मॉडल राज्य को संशोधित नहीं कर सकता है तो यह केवल स्वयं को गंदे या कुछ के रूप में चिह्नित करेगा। जब ViewModel को यह पता चलता है कि यह क्या गंदा है, अनुवाद करेगा और व्यू तब इसे महसूस करेगा और एक अन्य ट्रिगर के माध्यम से कुछ जानकारी दिखाएगा। View में सभी डेटा ViewModel से बंधे हो सकते हैं, इसलिए सब कुछ केवल डायनामिक हो सकता है मॉडल और ViewModel को इस बारे में बिलकुल भी अंदाजा नहीं है कि व्यू बाइंडिंग पर कैसे प्रतिक्रिया देगा। तथ्य की बात के रूप में मॉडल को एक ViewModel का कोई पता नहीं है। निर्भरता स्थापित करते समय उन्हें ऐसा करना चाहिए और केवल इतना पसंद करना चाहिए t राज्य को संशोधित करें तो यह केवल स्वयं को गंदे या कुछ के रूप में चिह्नित करेगा। जब ViewModel को यह पता चलता है कि यह क्या गंदा है, अनुवाद करेगा और व्यू तब इसे महसूस करेगा और एक अन्य ट्रिगर के माध्यम से कुछ जानकारी दिखाएगा। View में सभी डेटा ViewModel से बंधे हो सकते हैं, इसलिए सब कुछ केवल डायनामिक हो सकता है मॉडल और ViewModel को इस बारे में बिलकुल भी अंदाजा नहीं है कि व्यू बाइंडिंग पर कैसे प्रतिक्रिया देगा। तथ्य की बात के रूप में मॉडल को एक ViewModel का कोई पता नहीं है। निर्भरता स्थापित करते समय उन्हें ऐसा करना चाहिए और केवल इतना पसंद करना चाहिए t राज्य को संशोधित करें तो यह केवल स्वयं को गंदे या कुछ के रूप में चिह्नित करेगा। जब ViewModel को यह पता चलता है कि यह क्या गंदा है, अनुवाद करेगा और व्यू तब इसे महसूस करेगा और एक अन्य ट्रिगर के माध्यम से कुछ जानकारी दिखाएगा। View में सभी डेटा ViewModel से बंधे हो सकते हैं, इसलिए सब कुछ केवल डायनामिक हो सकता है मॉडल और ViewModel को इस बारे में बिलकुल भी अंदाजा नहीं है कि व्यू बाइंडिंग पर कैसे प्रतिक्रिया देगा। तथ्य की बात के रूप में मॉडल को एक ViewModel का कोई पता नहीं है। निर्भरता स्थापित करते समय उन्हें ऐसा करना चाहिए और केवल इतना पसंद करना चाहिए View में सभी डेटा ViewModel से बंधे हो सकते हैं, इसलिए सब कुछ केवल डायनामिक हो सकता है मॉडल और ViewModel को इस बारे में बिलकुल भी अंदाजा नहीं है कि व्यू बाइंडिंग पर कैसे प्रतिक्रिया देगा। तथ्य की बात के रूप में मॉडल को एक ViewModel का कोई पता नहीं है। निर्भरता स्थापित करते समय उन्हें ऐसा करना चाहिए और केवल इतना पसंद करना चाहिए View में सभी डेटा ViewModel से बंधे हो सकते हैं, इसलिए सब कुछ केवल डायनामिक हो सकता है मॉडल और ViewModel को इस बारे में बिलकुल भी अंदाजा नहीं है कि व्यू बाइंडिंग पर कैसे प्रतिक्रिया देगा। तथ्य की बात के रूप में मॉडल को एक ViewModel का कोई पता नहीं है। निर्भरता स्थापित करते समय उन्हें ऐसा करना चाहिए और केवल इतना पसंद करना चाहिएदेखें → ViewModel → मॉडल (और एक साइड नोट यहाँ ... और यह शायद तर्क के रूप में अच्छी तरह से तर्क दिया जाएगा, लेकिन मुझे परवाह नहीं है ... जब तक कि मॉडल अपरिवर्तनीय नहीं है, तब तक मॉडल को न देखें; अन्यथा इसे लपेटें उचित ViewModel। दृश्य को एक मॉडल अवधि नहीं दिखनी चाहिए। मैं एक चूहों को देता हूं कि आपने क्या डेमो देखा है या आपने इसे कैसे किया है, यह गलत है।)

यहाँ मेरा अंतिम टिप है ... एक अच्छी तरह से डिजाइन, अभी तक बहुत सरल, एमवीसी एप्लिकेशन को देखें और एमवीवीएम एप्लिकेशन के लिए भी ऐसा ही करें। एक का नियंत्रण शून्य लचीलेपन तक सीमित होगा जबकि दूसरे में कोई नियंत्रण और असीमित लचीलापन नहीं होगा।

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

अगर मैंने आपको भ्रमित नहीं किया है तो मुझसे संपर्क करने का पर्याप्त प्रयास करें ... मुझे इस पर पूर्ण विवरण और उदाहरणों के साथ विस्तार करने में कोई आपत्ति नहीं है।

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

Comments

आश्चर्यजनक विस्तृत और सटीक उत्तर! मेरे लिए इसे क्रिस्टल-क्लीयर बनाया। :-)

— अंकुश

"यह सीखना बहुत भ्रामक हो सकता है क्योंकि आपको नेट पर बहुत सारी जानकारी मिल जाएगी।" हां। जैसा कि किसी को लगता है कि इन डिजाइन पैटर्न के साथ बहुत अनुभव है, क्या आप किसी अच्छे ट्यूटोरियल / गाइड के बारे में जानते हैं?

— 1925 में MarredCheese

सच कहूं, तो मेरा एमवीवीएम ज्ञान वर्षों या परीक्षण और त्रुटि के माध्यम से रहा है और टीम के प्रयासों के आधार पर विभिन्न तरीकों से इसका उपयोग / कर रहा है। मैं हाल ही में (2 साल पहले) एक संक्षिप्त गेम प्लान में अपने अनुभव को डालने में सक्षम था और ऐसा करने के लिए एक टीम शुरू कर रहा था और हम बेहद सफल थे। उस ने कहा, मैं तुम्हें किसी एक स्थान पर इंगित नहीं कर सकता और माफी मांग सकता हूं। मैं कह सकता हूं कि आप सही हैं, क्योंकि विभिन्न रायों के कारण यह बहुत भ्रामक है लेकिन, IMO, MVVM के साथ यह यथासंभव सामान्य है। ViewModels को डेटा के साथ कड़ाई से लेकिन किसी भी दृश्य के लिए विचारों को बाँधने और काम करने की अनुमति देने में सक्षम बनाएं ...

— माइकल Puckett II

दूसरे शब्दों में, कभी भी ViewModel को देखने के लिए किसी भी तरह से एक दृश्य दिखेगा या कार्य करेगा। मेरे लिए ViewModel, एक एपीआई की तरह सबसे अच्छा उपयोग किया जाता है, लेकिन सख्त संचार के साथ। बाध्यकारी, संपादन, कमांडिंग, आदि के लिए गेम प्लान का पालन करें। यदि किसी विशिष्ट तरीके से कार्य करने के लिए व्यू को अतिरिक्त तर्क की आवश्यकता होती है, जिसका ऐप या डेटा (जैसे कोई एनीमेशन या ड्रॉपडाउन बॉक्स ..) से कोई लेना-देना नहीं है, तो वह तर्क व्यू टियर में किसी तरह से संबंधित है। फिर से, विचारों की अधिकता है और यह सिर्फ मेरा है लेकिन मेरे पास यहां एक मजबूत पृष्ठभूमि है और अब तक एक ठोस ट्रैक रिकॉर्ड है।

— माइकल पकेट द्वितीय

मेरे पास उदाहरण एप्लिकेशन हैं जिन्हें मैं साझा करने में कोई आपत्ति नहीं करता हूं और एक साधारण शो स्थापित करने में कोई आपत्ति नहीं करेगा और यदि आप चाहते हैं या उत्सुक हैं तो आप या किसी और को बताएं।

— माइकल पिकेट द्वितीय

Answer 9

एमवीवीएम प्रेजेंटेशन मॉडल पैटर्न का परिशोधन (डिबेटेबल) है । मैं डिबेटेबल कहता हूं, क्योंकि एकमात्र अंतर यह है कि कैसे WPF डेटा बाइंडिंग और कमांड हैंडलिंग करने की क्षमता प्रदान करता है।

Comments

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

— जॉन पीटर्स

मैंने यह कहा, 2009 में, क्योंकि अब तक समुदाय के कई लोगों ने इस जवाब को स्वीकार किया था। मैंने कहा कि यह बहस का मुद्दा था, क्योंकि एमवीवीएम और प्रस्तुति मॉडल वास्तव में अलग-अलग नामों से एक ही पैटर्न हैं। WPF में लोकप्रियता के लिए टैंक, इसे आज अन्य फ्रेमवर्क में MVVM कहा जाता है, लेकिन या तो नाम सटीक है।

— वीकेम्पफ

Answer 10

व्यूमॉडल आपके उपयोगकर्ता इंटरफ़ेस तत्वों के लिए एक "सार" मॉडल है। यह आपको अपने दृश्य में आदेशों और कार्यों को गैर-दृश्य तरीके से निष्पादित करने की अनुमति दे सकता है (उदाहरण के लिए इसका परीक्षण करना)।

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

एमवीवीएम पैटर्न केवल सभी यूआई तत्वों के लिए उस अभ्यास का सामान्यीकरण है।

और यह एक Microsoft पैटर्न नहीं है, जो यह कहता है कि WPF / सिल्वरलाइट डेटा-बाइंडिंग विशेष रूप से इस पैटर्न के साथ काम करने के लिए उपयुक्त हैं। उदाहरण के लिए, जावा सर्वर चेहरों के साथ इसका उपयोग करने के लिए कुछ भी नहीं रोकता है।

Answer 11

अन्य उत्तर उस व्यक्ति के लिए समझना आसान नहीं हो सकता है जो वास्तुशिल्प पैटर्न के विषय से बहुत परिचित नहीं है। कोई व्यक्ति जो ऐप आर्किटेक्चर में नया है, वह जानना चाहता है कि उसकी पसंद व्यवहार में उसके ऐप को कैसे प्रभावित कर सकती है और समुदायों में सभी उपद्रव के बारे में क्या है।

उपरोक्त पर कुछ प्रकाश डालने की कोशिश करते हुए, मैंने इस स्क्रीनप्ले को MVVM, MVP और MVC को शामिल किया। कहानी एक उपयोगकर्ता द्वारा फिल्म खोज ऐप में 'FIND' बटन पर क्लिक करने से शुरू होती है ...

उपयोगकर्ता: क्लिक करें ...

देखें : वह कौन है? [ MVVM | MVP | MVC ]

उपयोगकर्ता: मैंने बस खोज बटन पर क्लिक किया है ...

देखें : ठीक है, एक सेकंड पर पकड़ ...। [ MVVM | MVP | MVC ]

( देखें बुला ViewModel | प्रस्तुतकर्ता | नियंत्रक ...) [ MVVM | एमवीपी | MVC ]

देखें : अरे ViewModel | प्रस्तुतकर्ता | नियंत्रक , उपयोगकर्ता ने केवल खोज बटन पर क्लिक किया है, मुझे क्या करना चाहिए? [ MVVM | MVP | MVC ]

ViewModel | प्रस्तुतकर्ता | नियंत्रक : अरे देखिए , क्या उस पृष्ठ पर कोई खोज शब्द है? [ MVVM | MVP | MVC ]

देखें : हाँ, ... यहाँ यह है ... "पियानो" [ MVVM | MVP | MVC ]

- यह के बीच सबसे महत्वपूर्ण अंतर यह है MVVM और एमवीपी | MVC ——

प्रस्तुतकर्ता : धन्यवाद देखें , ... इस बीच मैं मॉडल पर खोज शब्द देख रहा हूं , कृपया उसे / उसे एक प्रगति बार दिखाएं [ MVP | MVC ]

( प्रस्तुतकर्ता | नियंत्रक मॉडल को बुला रहा है ...) [ एमवीपी | MVC ]

ViewController : धन्यवाद, मैं मॉडल पर खोज शब्द देख रहा हूं, लेकिन आपको सीधे अपडेट नहीं करेगा। इसके बजाय, यदि कोई परिणाम है, तो मैं ईवेंट्स को खोजता हूं। ListObservable इसलिए आपने उस पर बेहतर तरीके से गौर किया। [ MVVM ]

(SearchResultsListObservable में किसी भी ट्रिगर का अवलोकन करते समय, दृश्य यह सोचता है कि इसे उपयोगकर्ता को कुछ प्रगति बार दिखाना चाहिए, क्योंकि ViewModel उस पर इस पर बात नहीं करेगा)

------------------------------

ViewModel | प्रस्तुतकर्ता | नियंत्रक : अरे मॉडल , क्या आपके पास इस खोज शब्द का कोई मेल है ?: "पियानो" [ MVVM | एमवीपी | MVC ]

मॉडल : अरे ViewModel | प्रस्तुतकर्ता | नियंत्रक , मुझे जांचने दें… [ MVVM | एमवीपी | MVC ]

( मॉडल फिल्म डेटाबेस के लिए एक प्रश्न बना रहा है ...) [ MVVM | एमवीपी | MVC ]

( कुछ समय बाद … )

——— यह MVVM , MVP और MVC के बीच का विचलन बिंदु है ———

मॉडल : मुझे आपके लिए एक सूची मिली, ViewModel | प्रस्तुतकर्ता , यहाँ यह JSON "[{" नाम ":" पियानो शिक्षक "," वर्ष ": 2001}, {" नाम ":" पियानो "," वर्ष ": 1993}]" [ MVVM | MVP ]

मॉडल : कुछ परिणाम उपलब्ध है, नियंत्रक। मैंने अपने उदाहरण में एक फ़ील्ड चर बनाया है और इसे परिणाम के साथ भर दिया है। यह नाम है "searchResultsList" [ MVC ]

( प्रस्तुतकर्ता | नियंत्रक धन्यवाद मॉडल और करने के लिए वापस हो जाता है दृश्य ) [ एमवीपी | MVC ]

प्रस्तुतकर्ता : इंतजार कर के लिए धन्यवाद देखें , मैं तुम्हारे लिए परिणाम मिलान की एक सूची मिल गया है और एक आकर्षक स्वरूप में उन्हें व्यवस्था की: [ "पियानो टीचर 2001", "पियानो 1993"]। कृपया अब प्रगति बार को छिपाएँ [ MVP ]

नियंत्रक : इंतजार कर के लिए धन्यवाद देखें , मैं मॉडल अपनी खोज क्वेरी के बारे में पूछा है। यह कहता है कि यह मिलान के परिणामों की एक सूची पाया है और उन्हें अपने उदाहरण के अंदर "searchResultsList" नामक एक चर में संग्रहीत किया है। आप इसे वहां से प्राप्त कर सकते हैं। कृपया अब प्रगति बार को छिपाएँ [ MVC ]

ViewModel : searchResultsListObservable पर किसी भी पर्यवेक्षक को सूचित किया जा सकता है कि प्रस्तुत करने योग्य प्रारूप में यह नई सूची है: ["पियानो शिक्षक 2001 ″," पियानो 1993 "]। [ MVVM ]

देखें : बहुत बहुत धन्यवाद प्रस्तुतकर्ता [ एमवीपी ]

देखें : धन्यवाद " नियंत्रक " [ एमवीसी ] (अब दृश्य खुद से सवाल कर रहा है: मुझे मॉडल से प्राप्त होने वाले परिणामों को कैसे प्रस्तुत करना चाहिए से उपयोगकर्ता को करने चाहिए? क्या फिल्म का उत्पादन वर्ष पहले या आखिरी आना चाहिए ...?)

दृश्य : ओह, searchResultsListObservable में एक नया ट्रिगर है ... अच्छा, एक प्रस्तुत करने योग्य सूची है, अब मुझे इसे केवल एक सूची में दिखाना होगा। मुझे अब प्रगति पट्टी को भी छिपाना चाहिए कि मेरे पास परिणाम है। [ MVVM ]

यदि आप रुचि रखते हैं, तो मैंने यहां लेखों की एक श्रृंखला लिखी है एक फिल्म एंड्रॉइड ऐप को लागू करके MVVM, MVP और MVC की तुलना करते हुए, ।

Comments

यहाँ सभी फ्लेवर टेक्स्ट के अंतर्गत एक बढ़िया उत्तर है ... कुछ फ़ॉर्मेटिंग के साथ और घटकों के बीच छोटी सी बात को फेंकने से यह इस पृष्ठ पर सबसे अच्छा हो सकता है।

— neonblitzer

Answer 12

MVC का उपयोग करते हुए दृश्‍य में दृश्‍यमान दृश्‍यमानModels इंजेक्षन करना

1. नियंत्रक ViewModel को नया रूप देने और उसे दृश्य में इंजेक्ट करने के लिए जिम्मेदार है। (अनुरोध प्राप्त करने के लिए)
2. ViewModel DataContext और दृश्य स्थिति जैसे अंतिम चयनित आइटम आदि के लिए कंटेनर है।
3. मॉडल में DB इकाइयां शामिल हैं और यह DB स्कीमा के बहुत करीब है और यह क्वेरी और फ़िल्टरिंग करता है। (मुझे इसके लिए EF और LINQ पसंद है)
4. मॉडल को भी रिपॉजिटरी पर विचार करना चाहिए या मजबूत प्रकारों में परिणामों के प्रक्षेपण (ईएफ के पास एक बढ़िया तरीका है ... ईएफ.डाटेस.सेलेक्ट (क्वेरिस्ट्रिंग, पैरा) प्रश्नों को इंजेक्ट करने और मजबूत प्रकार वापस पाने के लिए सीधे एडीओ एक्सेस के लिए। यह एफएफ को संबोधित करता है। धीमी गति से तर्क है। ईएफ धीमी नहीं है !
5. ViewModel डेटा प्राप्त करता है और व्यापार नियम और सत्यापन करता है
6. वापस पोस्ट पर नियंत्रक ViewModel पोस्ट विधि को शांत करेगा और परिणामों की प्रतीक्षा करेगा।
7. नियंत्रक नए अपडेट किए गए Viewmodel को दृश्य में इंजेक्ट करेगा। व्यू केवल मजबूत टाइप बाइंडिंग का उपयोग करता है ।
8. दृश्य केवल डेटा को प्रस्तुत करता है, और घटनाओं को नियंत्रक को वापस पोस्ट करता है। (नीचे दिए गए उदाहरण देखें)
9. MVC इनबाउंड अनुरोध को स्वीकार करता है और इसे मजबूत डेटा प्रकार के साथ उचित नियंत्रक के लिए रूट करता है

इस मॉडल में अनुरोध या प्रतिक्रिया वस्तुओं के साथ अधिक HTTP स्तर का संपर्क नहीं है क्योंकि MSFT की MVC मशीन इसे हमसे छिपाती है।

आइटम 6 के स्पष्टीकरण में ऊपर (अनुरोध द्वारा) ...

इस तरह एक ViewModel मान लें:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

पोस्ट की नियंत्रक विधि इस तरह दिखेगी (नीचे देखें), ध्यान दें कि एमवीसी बंधन तंत्र द्वारा mvm का उदाहरण स्वचालित रूप से इंस्टिंक्ट किया जाता है। आपको परिणाम के रूप में क्वेरी स्ट्रिंग लेयर पर नीचे नहीं जाना है! यह MVC क्वेरी स्ट्रिंग्स के आधार पर आपके लिए ViewModel को तत्काल तैयार करना है!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

ध्यान दें कि इस एक्शनमेथोड के लिए ऊपर काम करने के लिए जैसा कि आप चाहते हैं, आपके पास एक शून्य सीटीओआर होना चाहिए जो यह बताता है कि पोस्ट में वापस नहीं आने वाली चीजों को बरकरार रखता है। पोस्ट बैक को उन चीजों के लिए बैक नाम / मूल्य जोड़े भी पोस्ट करना चाहिए जो बदल गए। यदि लापता नाम / मान जोड़े हैं तो MVC बाइंडिंग इंजन उचित काम करता है जो कि बस कुछ भी नहीं है! यदि ऐसा होता है तो आप खुद कह सकते हैं कि "मैं पोस्ट बैक पर डेटा खो रहा हूं" ...

इस पैटर्न का लाभ ViewModel मॉडल / Buisness लॉजिक के लिए सभी "अव्यवस्था" कार्य करता है, नियंत्रक केवल एक राउटर है। यह कार्रवाई में एसओसी है।

Comments

क्या आप आइटम 6 को स्पष्ट कर सकते हैं? मुझे लगता है कि आप ASP.Net को ही कवर कर रहे हैं, लेकिन यह ViewModel के लिए एक अवांछित निर्भरता जोड़ता है। (उदाहरण के लिए डेटा कहाँ से आता है / जाता है) का ज्ञान। एक कोड (छद्म कोड?) उदाहरण इस उत्तर को स्पष्ट करने और यह दिखाने के लिए अच्छा होगा कि कौन से हिस्से सर्वर-साइड हैं और कौन से क्लाइंट-साइड हैं।

— कोडिंग हुआ

Answer 13

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

मैं गलत हो सकता हूं, लेकिन मुझे यकीन नहीं है कि एमवीवीएम वास्तव में मिश्रण में नियंत्रक को मजबूर करता है। मुझे इस अवधारणा के साथ अधिक जानकारी मिलती है: http://martinfowler.com/eaaDev/PresentationModel.html । मुझे लगता है कि लोग इसे MVC के साथ संयोजित करना चुनते हैं, न कि यह कि इसे पैटर्न में बनाया गया है।

Comments

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

— वीकेम्पफ

माना। MVC में Viewmodel "IS" दृश्य के लिए राज्य मशीन है। इसमें डेटाकोटेक्स्ट शामिल है और सभी चयनित आइटम सूचनाओं को ट्रैक करता है और साथ ही IValidatableObject इंटरफ़ेस का उपयोग करके सभी सत्यापन तर्क शामिल कर सकता है। ViewModel मॉडल परत पर DB के साथ इंटरफेस करता है जो मजबूत टाइप किए गए मॉडल का उपयोग कर सकता है। WPF में MVVM MVC का नियंत्रक है। लेकिन एमवीसी का नियंत्रक ज्यादा साफ-सुथरा है, यह एक रूटिंग हैंडलर है।

— जॉन पीटर्स

Answer 14

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

Comments

IMHO मैं तर्क था कि "नियंत्रकों अधिक पुन: प्रयोज्य बनाने" बहुत व्यापक सामान्य ASP.Net "नियंत्रक" के लिए एक बयान और प्रतिकूल है (यानी नहीं व्यापार तर्क परत) के रूप में उन नियंत्रकों आम तौर पर आवेदन के कुछ हिस्सों कि होते हैं आवेदन के विशिष्ट । यह दृश्य, मॉडल, ViewModels और व्यापार तर्क है जिसे पुन: प्रयोज्य होने की आवश्यकता है। मैंने सोचा होगा कि बिजनेस लॉजिक मॉड्यूल को सर्विस प्रोवाइडर के रूप में नहीं, कंट्रोलर के रूप में देखा जाए तो यह एक बेहतर विकल्प होगा।

— कोडिंग चला गया

लेकिन आप Asp.net में "ViewModel" के बारे में बात कर रहे हैं, MVVM डिज़ाइन पैटर्न के बारे में नहीं। दो अलग बातें।

— लुइस

Answer 15

यह मुझे आश्चर्यचकित करता है कि यह MVVM की उत्पत्ति का उल्लेख किए बिना एक अत्यधिक मतदान के उत्तर हैं । MVVM एक लोकप्रिय शब्द है जिसका उपयोग Microsoft समुदाय में किया जाता है और यह मार्टिन फाउलर के प्रस्तुति मॉडल से उत्पन्न हुआ है । तो पैटर्न के उद्देश्य और दूसरों के साथ मतभेदों को समझने के लिए, पैटर्न के बारे में मूल लेख पढ़ने के लिए पहली बात है।

Comments

वाह ... तो MVC और MVVM दोनों SmallTalk से आए ?? वे स्पष्ट रूप से अपने समय से आगे थे ...

— मैट

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

— वीकेम्पफ

Answer 16

खैर, आमतौर पर MVC का उपयोग वेब विकास में किया जाता है और MVVM WPF / सिल्वरलाइट विकास में सबसे लोकप्रिय है। हालांकि, कभी-कभी वेब आर्किटेक्चर में MVC और MVVM का मिश्रण हो सकता है।

उदाहरण के लिए: आप नॉकआउट का उपयोग कर सकते हैं। जेएस और इस मामले में आपके ग्राहक पक्ष में एमवीवीएम होगा। और आपका MVC का सर्वर पक्ष भी बदल सकता है। जटिल ऐप्स में, कोई भी शुद्ध मॉडल का उपयोग नहीं करता है। यह MVC के "मॉडल" के रूप में एक ViewModel का उपयोग करने की भावना हो सकती है और आपका वास्तविक मॉडल मूल रूप से इस वीएम का एक हिस्सा होगा। यह आपको एक अतिरिक्त अमूर्त परत देता है।

Comments

क्या 'वेब विकास' शब्द 'MVC' चिंताओं को अलग करने से ज्यादा कुछ नहीं है और न ही प्रामाणिक MVC जो वेब से पहले था।

— टेरेंस ब्रानोन

Answer 17

MVVMC, या शायद MVC +, उद्यम के साथ-साथ तेजी से अनुप्रयोग विकास के लिए एक व्यवहार्य दृष्टिकोण प्रतीत होता है। हालांकि यूआई को व्यवसाय और इंटरैक्शन लॉजिक से अलग करना अच्छा है, लेकिन 'शुद्ध' एमवीवीएम पैटर्न और अधिकांश उपलब्ध उदाहरण एकवचन विचारों पर सबसे अच्छा काम करते हैं।

आपके डिज़ाइन के बारे में निश्चित नहीं है, लेकिन मेरे अधिकांश अनुप्रयोगों में, हालांकि, पृष्ठ और कई (पुन: प्रयोज्य) दृश्य शामिल हैं और इस तरह ViewModels को कुछ हद तक बातचीत करने की आवश्यकता है। पेज को कंट्रोलर के रूप में उपयोग करने से MVVM का उद्देश्य पूरी तरह से समाप्त हो जाएगा, इसलिए अंतर्निहित तर्क के लिए "VM-C" दृष्टिकोण का उपयोग न करने से आवेदन परिपक्वता के रूप में .. अच्छी तरह से चुनौतीपूर्ण निर्माण हो सकता है। VB-6 में भी हम में से ज्यादातर ने शायद बटन लॉजिक में कोडिंग बिजनेस लॉजिक को बंद कर दिया और कंट्रोलर को 'रिलेटेड' कमांड देना शुरू कर दिया, है ना? मैंने हाल ही में उस विषय पर कई उभरते हुए फ्रेमवर्क को देखा; मेरा पसंदीदा स्पष्ट रूप से मैगलन (कोडप्लेक्स में) दृष्टिकोण है। हैप्पी कोडिंग!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

Answer 18

MVVM में नियंत्रक को ViewModel द्वारा प्रतिस्थापित नहीं किया जाता है, क्योंकि ViewModel की एक पूर्ण भिन्न कार्यक्षमता होती है, फिर एक नियंत्रक। आपको अभी भी एक नियंत्रक की आवश्यकता है, क्योंकि एक नियंत्रक के बिना आपका मॉडल, ViewModel और View बहुत कुछ नहीं करेगा ... MVVM में आपके पास एक नियंत्रक भी है, MVVM नाम केवल भ्रामक है।

मेरी विनम्र राय में MVVMC सही नाम है।

जैसा कि आप देख सकते हैं ViewModel MVC पैटर्न के लिए एक अतिरिक्त है। यह नियंत्रक से ViewModel में रूपांतरण-तर्क (उदाहरण के लिए एक स्ट्रिंग में ऑब्जेक्ट परिवर्तित) को स्थानांतरित करता है।

Answer 19

मैंने इसके लिए एक माध्यम लेख बनाया।

MVVM

1. देखें ➡ ViewModel od मॉडल

   • दृश्य में ViewModel का संदर्भ है लेकिन इसके विपरीत नहीं।
   • व्यूमॉडल में मॉडल का संदर्भ है लेकिन इसके विपरीत नहीं।
   • दृश्य में मॉडल और इसके विपरीत का कोई संदर्भ नहीं है।

2. यदि आप एक नियंत्रक का उपयोग कर रहे हैं, तो इसमें दृश्य और ViewModels का संदर्भ हो सकता है , हालांकि SwiftUI में प्रदर्शित के रूप में एक नियंत्रक हमेशा आवश्यक नहीं होता है ।

3. डेटा बाइंडिंग : हम ViewModel प्रॉपर्टीज़ के लिए श्रोता बनाते हैं।

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

सेटअप में अंतर

1. व्यवसाय तर्क MVC के लिए नियंत्रक और MVVM के लिए ViewModels में आयोजित किया जाता है।
2. एमवीसी में इवेंट्स को व्यू से कंट्रोलर तक सीधे पास किया जाता है जबकि एमवीवीएम के लिए व्यू से व्यूमोडेल तक कंट्रोलर (अगर कोई है तो) से इवेंट पास किए जाते हैं।

आम सुविधाएं

1. एमवीवीएम और एमवीसी दोनों ही दृश्य को सीधे मॉडल / एस को संदेश भेजने की अनुमति नहीं देते हैं।
2. दोनों के मॉडल हैं।
3. दोनों के विचार हैं।

MVVM के लाभ

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

MVC के लाभ

1. नियंत्रक के भीतर व्यावसायिक तर्क प्रदान करने से शाखाकरण की आवश्यकता कम हो जाती है और इसलिए कथन कैश पर चलने की अधिक संभावना होती है जो व्यावसायिक तर्क को ViewModels में एन्कैप करने से अधिक प्रदर्शनकारी होता है।
2. एक स्थान पर व्यावसायिक तर्क प्रदान करने से सरल अनुप्रयोगों के लिए विकास प्रक्रिया में तेजी आ सकती है, जहां परीक्षणों की आवश्यकता नहीं होती है। मुझे नहीं पता कि कब परीक्षणों की आवश्यकता नहीं है।
3. ViewController में व्यावसायिक तर्क प्रदान करना नए डेवलपर्स के बारे में सोचना आसान है।

Comments

सर्वश्रेष्ठ स्पष्टीकरण

— p32094

Answer 20

व्यावहारिक दृष्टिकोण से, एमवीसी (मॉडल-व्यू-कंट्रोलर) एक पैटर्न है। हालांकि, MVC जब ASP.net MVC के रूप में उपयोग किया जाता है, जब इकाई फ्रेमवर्क (EF) और "पावर टूल्स" के साथ संयुक्त होता है, तो डेटाबेस, तालिकाओं और स्तंभों को वेब पेज पर लाने के लिए पूर्ण रूप से या तो पूर्ण रूप से एक बहुत शक्तिशाली, आंशिक रूप से स्वचालित तरीका है। केवल CRUD ऑपरेशन या R (पुनः प्राप्त या पढ़ें) ऑपरेशन। कम से कम जैसा कि मैंने MVVM का उपयोग किया है, व्यू मॉडल्स ने व्यावसायिक वस्तुओं पर निर्भर रहने वाले मॉडल के साथ बातचीत की, जो बदले में "हाथ से बने" थे और बहुत प्रयास के बाद, मॉडल भाग्यशाली थे कि ईएफ एक देता है जितना अच्छा है। के--बॉक्स "। एक व्यावहारिक प्रोग्रामिंग दृष्टिकोण से, एमवीसी एक अच्छा विकल्प लगता है क्योंकि यह एक बहुत अधिक उपयोगिता आउट-ऑफ-बॉक्स देता है, लेकिन अभी भी घंटियाँ और सीटी जोड़ने की क्षमता है।

Answer 21

दी गई कई प्रतिक्रियाओं के लिए, मैं मॉडर्न क्लाइंट-साइड वेब - या रिच वेब एप्लिकेशन से कुछ अतिरिक्त परिप्रेक्ष्य जोड़ना चाहता था ।

दरअसल इन दिनों साधारण वेब साइट और बड़े वेब एप्लिकेशन आमतौर पर बूटस्ट्रैप जैसे कई लोकप्रिय पुस्तकालयों के साथ बनाए जाते हैं। स्टीव सैंडरसन द्वारा निर्मित, नॉकआउट एमवीवीएम पैटर्न के लिए समर्थन प्रदान करता है जो पैटर्न में सबसे महत्वपूर्ण व्यवहारों में से एक की नकल करता है: व्यू मॉडल के माध्यम से डेटा-बाइंडिंग। थोड़ा जावास्क्रिप्ट के साथ, डेटा और तर्क को लागू किया जा सकता है जो कि बूटस्ट्रैपdata-bind की कई विशेषताओं का उपयोग करके समान HTML विशेषताओं के साथ पृष्ठ तत्वों में जोड़ा जा सकता है । एक साथ, ये दो पुस्तकालय अकेले इंटरैक्टिव सामग्री प्रदान करते हैं; और जब इस दृष्टिकोण को रूट करने के साथ संयुक्त किया जाता है, तो सिंगल पेज एप्लिकेशन के निर्माण के लिए एक सरल-शक्तिशाली तरीका हो सकता है ।

इसी तरह, एक आधुनिक क्लाइंट-साइड फ्रेमवर्क जैसे कि एंगुलर कन्वेंशन द्वारा एमवीसी पैटर्न का पालन करता है, लेकिन एक सेवा भी जोड़ता है। दिलचस्प बात यह है कि इसे मॉडल-व्यू-जो भी (एमवीडब्ल्यू) के रूप में जाना जाता है। ( स्टैक ओवरफ्लो पर इस पोस्ट को देखें ।)

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

Answer 22

मुझे लगता था कि एमवीसी और एमवीवीएम एक ही हैं। अब फ्लक्स के अस्तित्व के कारण मैं अंतर बता सकता हूं:

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

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

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

Answer 23

mvc सर्वर-साइड है और mvvm वेब डेवलपमेंट में क्लाइंट-साइड (ब्राउज़र) है।

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

Answer 24

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

Answer 25

मॉडल-व्यू-नियंत्रक (आमतौर पर MVC के रूप में जाना जाता है ) एक सॉफ्टवेयर डिज़ाइन पैटर्न है जो आमतौर पर उपयोगकर्ता के इंटरफेस को विकसित करने के लिए उपयोग किया जाता है जो संबंधित प्रोग्राम लॉजिक को तीन परस्पर तत्वों में विभाजित करता है। यह उपयोगकर्ता द्वारा प्रस्तुत और स्वीकार किए जाने वाले तरीकों से जानकारी के आंतरिक अभ्यावेदन को अलग करने के लिए किया जाता है। एमवीसी वास्तुशिल्प पैटर्न के बाद कोड के पुन: उपयोग और समानांतर विकास की अनुमति देने वाले इन प्रमुख घटकों को डिकॉय करता है।

परंपरागत रूप से डेस्कटॉप ग्राफिकल यूजर इंटरफेस (GUIs) के लिए उपयोग किया जाता है, यह पैटर्न वेब एप्लिकेशन डिजाइन करने के लिए लोकप्रिय हो गया है। जावास्क्रिप्ट, पायथन, रूबी, पीएचपी, जावा और सी # जैसी लोकप्रिय प्रोग्रामिंग भाषाओं में एमवीसी फ्रेमवर्क हैं जो वेब एप्लिकेशन डेवलपमेंट में सीधे उपयोग किए जाते हैं।

नमूना

पैटर्न का केंद्रीय घटक। यह उपयोगकर्ता इंटरफ़ेस से स्वतंत्र अनुप्रयोग की गतिशील डेटा संरचना है। यह सीधे आवेदन के डेटा, तर्क और नियमों का प्रबंधन करता है।

राय

किसी भी जानकारी जैसे चार्ट, डायग्राम या टेबल का प्रतिनिधित्व। एक ही जानकारी के कई दृश्य संभव हैं, जैसे प्रबंधन के लिए एक बार चार्ट और एकाउंटेंट के लिए एक सारणीबद्ध दृश्य।

नियंत्रक

इनपुट स्वीकार करता है और इसे मॉडल या दृश्य के लिए कमांड में परिवर्तित करता है।

इन घटकों में एप्लिकेशन को विभाजित करने के अलावा, मॉडल-व्यू-कंट्रोलर डिज़ाइन उनके बीच बातचीत को परिभाषित करता है।

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

दृश्य का अर्थ है किसी विशेष प्रारूप में मॉडल की प्रस्तुति।

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

मॉडल-व्यू-व्यूमॉडल (एमवीवीएम) एक सॉफ्टवेयर आर्किटेक्चरल पैटर्न है।

MVVM ग्राफिकल यूजर इंटरफेस के विकास को अलग करने की सुविधा देता है - यह मार्कअप लैंग्वेज या GUI कोड के माध्यम से होता है - बिजनेस लॉजिक या बैक-एंड लॉजिक (डेटा मॉडल) के विकास से। एमवीवीएम का दृश्य मॉडल एक मूल्य परिवर्तक है, जिसका अर्थ है कि दृश्य मॉडल मॉडल से डेटा ऑब्जेक्ट को इस तरह से उजागर (परिवर्तित) करने के लिए ज़िम्मेदार है कि ऑब्जेक्ट आसानी से प्रबंधित और प्रस्तुत किए जाते हैं। इस संबंध में, दृश्य मॉडल एक दृश्य की तुलना में अधिक मॉडल है और सबसे अधिक संभालता है यदि दृश्य के सभी तर्क तर्क नहीं हैं। दृश्य मॉडल एक मध्यस्थ पैटर्न को लागू कर सकता है, दृश्य द्वारा समर्थित उपयोग मामलों के सेट के आसपास बैक-एंड तर्क तक पहुंच का आयोजन करता है।

MVVM मार्टिन फाउलर की प्रस्तुति मॉडल डिजाइन पैटर्न का एक रूपांतर है। MVVM एक दृश्य की स्थिति और व्यवहार को उसी तरह से अमूर्त करता है, लेकिन एक प्रस्तुति मॉडल एक दृश्य को बनाता है (एक दृश्य मॉडल बनाता है) एक विशिष्ट उपयोगकर्ता-इंटरफ़ेस प्लेटफ़ॉर्म पर निर्भर नहीं करता है।

MVVM का आविष्कार Microsoft आर्किटेक्ट केन कूपर और टेड पीटर्स ने विशेष रूप से उपयोगकर्ता इंटरफेस की घटना-संचालित प्रोग्रामिंग को सरल बनाने के लिए किया था। पैटर्न को विंडोज प्रेजेंटेशन फाउंडेशन (WPF) (Microsoft के .NET ग्राफिक्स सिस्टम) और सिल्वरलाइट (WPF के इंटरनेट एप्लिकेशन व्युत्पन्न) में शामिल किया गया था। माइक्रोसॉफ्ट के WPF और सिल्वरलाइट आर्किटेक्ट में से एक, जॉन गोस्मान ने 2005 में अपने ब्लॉग पर MVVM की घोषणा की।

मॉडल-व्यू-व्यू-मोडेल को मॉडल-व्यू-बाइंडर के रूप में भी जाना जाता है, विशेष रूप से कार्यान्वयन में। .NET प्लेटफ़ॉर्म शामिल नहीं है। ZK (जावा में लिखित एक वेब एप्लीकेशन फ्रेमवर्क) और नॉकआउट जेएस (एक जावास्क्रिप्ट लाइब्रेरी) मॉडल-व्यू-बाइंडर का उपयोग करते हैं।