MVVM की मूल अवधारणाएं- ViewModel को क्या करना चाहिए?


83

एमवीवीएम की अवधारणाओं को समझने की कोशिश करते हुए, मैंने पहले ही कई ब्लॉग पढ़े हैं और कुछ परियोजनाओं को देखा है।

जो मैं समझता हूं, वह एक दृश्य गूंगा है, यह सिर्फ यह जानता है कि इसे कैसे पारित किया जाए।

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

लेकिन मुझे अभी तक यह पता नहीं है कि अवधारणा को कैसे लागू किया जाए। क्या कोई बहुत सरल परिदृश्य समझा सकता है ताकि मैं अवधारणा को समझ सकूं? मैंने पहले ही कई परियोजनाओं पर ध्यान दिया है, लेकिन यह अभी भी पूरी तरह से समझ में नहीं आता है, इसलिए अगर कोई इसे सीधे सादे अंग्रेजी में लिख सकता है, तो यह अच्छा होगा।


2
उस कथन से सहमत नहीं हो सकता है, जिसे "केवल यह पता है कि उसे कैसे पारित किया जाए।" देखें VM से डेटा लेता है। कोई भी इसे डेटा पास नहीं करता है। देखने के बारे में कोई नहीं जानता। यह एमवीपी से एक महत्वपूर्ण अंतर है। MVP में (यू इसे कोडबाइंड लॉजिक के साथ एक साधारण WPF एप्लिकेशन के बारे में सोच सकते हैं, यह एक MVP पैटर्न है) कोडबेहिंड एक प्रस्तोता है जो आपके कहे अनुसार व्यू को डेटा पास करता है।
ग्रिगोरी

जवाबों:


146

मैं इसे इस तरह से सोचना पसंद करता हूं:

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

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

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

मेरे लिए, सबसे भ्रामक बिट्स निम्नलिखित थे:

  • भले ही viewmodels एक चित्रमय अनुप्रयोग के मॉडल हैं, लेकिन वे सीधे दृश्य अवधारणाओं का संदर्भ या उपयोग नहीं करते हैं। उदाहरण के लिए, आप अपने ViewModels में Windows नियंत्रण के संदर्भ नहीं चाहते हैं - वे चीजें दृश्य में जाती हैं। ViewModels बस डेटा और व्यवहार को नियंत्रित करने के लिए या अन्य वस्तुओं को उजागर करता है जो उन्हें बांधेंगे। उदाहरण के लिए - क्या आपके पास इसमें लिस्टबॉक्स के साथ एक दृश्य है? आपका व्यूमॉडल लगभग निश्चित रूप से इसमें किसी प्रकार का संग्रह है। क्या आपके विचार में बटन हैं? आपका दृश्यमॉडल लगभग निश्चित रूप से इसमें कुछ कमांड रखने वाला है।
  • कुछ प्रकार की वस्तुएं हैं जिन्हें "दृश्यमॉडल" माना जा सकता है। समझने के लिए सरलतम प्रकार का दृश्य वह है जो सीधे 1: 1 संबंध में एक नियंत्रण या स्क्रीन का प्रतिनिधित्व करता है, जैसा कि "स्क्रीन में XYZ में एक टेक्स्टबॉक्स, एक सूची बॉक्स और तीन बटन होते हैं, इसलिए दृश्यमॉडल को एक स्ट्रिंग, एक संग्रह की आवश्यकता होती है, और तीन आज्ञाएँ। " एक अन्य प्रकार की वस्तु जो दृश्यमॉडल परत में फिट होती है, एक मॉडल ऑब्जेक्ट के चारों ओर एक आवरण होता है जो इसे व्यवहार देता है और इसे एक दृश्य द्वारा अधिक प्रयोग करने योग्य बनाता है - यह वह जगह है जहां आप "मोटी" और "पतली" दृश्यमॉडल परतों की अवधारणाओं में मिलते हैं। एक "पतली" दृश्यमॉडल परत दृश्यमॉडल का एक सेट है जो आपके मॉडल ऑब्जेक्ट्स को सीधे विचारों से उजागर करता है, जिसका अर्थ है कि मॉडल ऑब्जेक्ट्स पर सीधे संपत्तियों के लिए बाइंडिंग समाप्त होती है। यह सरल, केवल पढ़ने वाले विचारों जैसी चीजों के लिए काम कर सकता है, लेकिन क्या होगा अगर आप प्रत्येक वस्तु के साथ व्यवहार करना चाहते हैं? आप मॉडल में ऐसा नहीं चाहते, क्योंकि मॉडल एप्लिकेशन से संबंधित नहीं है, यह केवल आपके डोमेन से संबंधित है। आप इसे एक ऐसी वस्तु में रख सकते हैं जो आपके मॉडल ऑब्जेक्ट को लपेटता है और अधिक बाध्यकारी-अनुकूल डेटा और व्यवहार प्रदान करता है। इस आवरण वस्तु को भी एक दृश्यदर्शी माना जाता है, और उनके परिणामस्वरूप "मोटी" दृश्यमॉडल परत होती है, जहां आपके विचार कभी भी मॉडल वर्ग पर किसी भी चीज़ के लिए सीधे बाध्यकारी नहीं होते हैं। कलेक्शन में व्यूमॉडल शामिल होंगे जो केवल खुद को मॉडल रखने के बजाय मॉडल लपेटते हैं। आप इसे एक ऐसी वस्तु में रख सकते हैं जो आपके मॉडल ऑब्जेक्ट को लपेटता है और अधिक बाध्यकारी-अनुकूल डेटा और व्यवहार प्रदान करता है। इस आवरण वस्तु को एक दृश्यदर्शी भी माना जाता है, और उनके परिणामस्वरूप "मोटी" दृश्यमॉडल परत होती है, जहां आपके विचार कभी भी मॉडल वर्ग पर किसी भी चीज़ के लिए सीधे बाध्यकारी नहीं होते हैं। कलेक्शन में व्यूमॉडल शामिल होंगे जो केवल स्वयं के मॉडल वाले मॉडल के बजाय लपेटते हैं। आप इसे एक ऐसी वस्तु में रख सकते हैं जो आपके मॉडल ऑब्जेक्ट को लपेटता है और अधिक बाध्यकारी-अनुकूल डेटा और व्यवहार प्रदान करता है। इस आवरण वस्तु को एक दृश्यदर्शी भी माना जाता है, और उनके परिणामस्वरूप "मोटी" दृश्यमॉडल परत होती है, जहां आपके विचार कभी भी मॉडल वर्ग पर किसी भी चीज़ के लिए सीधे बाध्यकारी नहीं होते हैं। कलेक्शन में व्यूमॉडल शामिल होंगे जो केवल खुद को मॉडल रखने के बजाय मॉडल लपेटते हैं।

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


3
+1 - मैं यहां समाप्त हुआ क्योंकि मैं एक "रैपर" ViewModel द्वारा भ्रमित किया गया था जो कुछ नमूना कोड में सामना किया गया था। क्लीयर करने के लिए धन्यवाद मेरे लिए :-)
Riegardt Steyn

1
शानदार जवाब - काश मैं +10 कर पाता।
निक होजेस

1
@nlawalker बहुत कमाल! ऊपर यू डबल बिट्स टिप्पणी मुझे बहुत लंबे समय के लिए भ्रमित कर रहा है। किसी भी लेख और ब्लॉग केवल MVVM की "प्रमुख विशेषताओं" को बताता है, लेकिन जब यू इसके साथ प्राप्त करने की कोशिश करते हैं, तो चीजें बहुत जटिल होने लगती हैं ? जैसे "उन दृश्यों को कैसे नेविगेट करें?" "जब हम ViewModels डिज़ाइन करते हैं तो उपयुक्त ग्रैन्युलैरिटी क्या होती है?" "एक दृश्य का मिलान किया हुआ व्यूमॉडल है या क्या एक व्यूमॉडल का विभिन्न दृश्यों में पुन: उपयोग किया जा सकता है?" "स्लिम वीएम" और "थिक वीएम" के साथ रचित व्यूमॉडल के बारे में आपका स्पष्टीकरण वास्तव में समझ में आता है! मैं कोशिश कर रहा हूं, यह अच्छी तरह से काम करता है। दूर! :)
पंजा

@nlawalker धन्यवाद! और एक और सवाल: मेरे पास ट्री व्यू है और ट्री व्यू व्यूमॉडल बनाओ। इसलिए, अगर मैं इस तरह के तरीके बनाता हूं: मेरे ViewModel पर ExpandTree ()। क्या यह सही तरीका है?
user2545071

वाह, यह एक उत्कृष्ट लेख है, बहुत अच्छा काम @nlawalker
विवेक शुक्ला

25

स्रोत के रूप में इस अविश्वसनीय रूप से उपयोगी लेख का उपयोग करना , यहां व्यू , व्यूमॉडल और मॉडल के लिए एक सारांश है ।


राय:

  • दृश्य एक दृश्य तत्व है, जैसे कि एक विंडो, पृष्ठ, उपयोगकर्ता नियंत्रण या डेटा टेम्पलेट। दृश्य दृश्य में निहित नियंत्रण और उनके दृश्य लेआउट और स्टाइल को परिभाषित करता है।

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

  • दृश्य और दृश्य मॉडल के बीच डेटा बाइंडिंग व्यवहार को अनुकूलित कर सकता है। उदाहरण के लिए, दृश्य यूआई में प्रदर्शित होने वाले डेटा को प्रारूपित करने के लिए मूल्य कन्वर्टर्स का उपयोग कर सकता है, या उपयोगकर्ता को अतिरिक्त इनपुट डेटा सत्यापन प्रदान करने के लिए सत्यापन नियमों का उपयोग कर सकता है।

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

  • दृश्य के कोड-पीछे दृश्य व्यवहार को लागू करने के लिए यूआई तर्क को परिभाषित कर सकता है जो एक्सएएमएल में व्यक्त करना मुश्किल है या जिसे दृश्य में परिभाषित विशिष्ट यूआई नियंत्रणों के लिए सीधे संदर्भ की आवश्यकता होती है।

नोट:
क्योंकि दृश्य मॉडल में दृश्य में विशिष्ट दृश्य तत्वों का कोई स्पष्ट ज्ञान नहीं होना चाहिए, दृश्य के भीतर दृश्य तत्वों को प्रोग्रामेटिक रूप से हेरफेर करने के लिए कोड को दृश्य के कोड-पीछे रहना चाहिए या किसी व्यवहार में संलग्न होना चाहिए।


देखें मॉडल:

  • दृश्य मॉडल एक गैर-दृश्य वर्ग है और किसी भी WPF या सिल्वरलाइट बेस क्लास से नहीं निकलता है। यह एप्लिकेशन में उपयोग के मामले या उपयोगकर्ता के कार्य का समर्थन करने के लिए आवश्यक प्रस्तुति तर्क को एन्क्रिप्ट करता है। दृश्य मॉडल दृश्य और मॉडल के स्वतंत्र रूप से परीक्षण करने योग्य है।

  • दृश्य मॉडल आमतौर पर दृश्य को सीधे संदर्भित नहीं करता है। यह उन गुणों और आदेशों को लागू करता है जिनके लिए दृश्य डेटा बाइंड कर सकता है। यह परिवर्तन सूचनाओं के माध्यम से INotifyPropertyChangedऔर INotifyCollectionChangedइंटरफेस के माध्यम से किसी भी राज्य के परिवर्तन के दृश्य को सूचित करता है।

  • दृश्य मॉडल मॉडल के साथ दृश्य की बातचीत का समन्वय करता है। यह डेटा को परिवर्तित या हेरफेर कर सकता है ताकि इसे आसानी से देखा जा सके और अतिरिक्त गुणों को लागू कर सके जो मॉडल पर मौजूद नहीं हो सकते हैं। यह डेटा सत्यापन को IDataErrorInfoया INotifyDataErrorInfoइंटरफेस के माध्यम से भी लागू कर सकता है।

  • दृश्य मॉडल तार्किक स्थिति को परिभाषित कर सकता है कि दृश्य उपयोगकर्ता को नेत्रहीन रूप से प्रस्तुत कर सकता है।

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


नमूना:

  • मॉडल कक्षाएं गैर-दृश्य कक्षाएं हैं जो एप्लिकेशन के डेटा और व्यावसायिक तर्क को एन्क्रिप्ट करती हैं। वे एप्लिकेशन के डेटा को प्रबंधित करने और आवश्यक व्यावसायिक नियमों और डेटा सत्यापन तर्क को संलग्न करके इसकी स्थिरता और वैधता सुनिश्चित करने के लिए जिम्मेदार हैं।

  • मॉडल कक्षाएं सीधे मॉडल कक्षाओं को देखने या देखने का संदर्भ नहीं देती हैं और इस पर कोई निर्भरता नहीं है कि उन्हें कैसे लागू किया जाता है।

  • मॉडल कक्षाएं आम तौर पर संपत्ति और संग्रह परिवर्तन अधिसूचना घटनाओं के माध्यम से INotifyPropertyChangedऔर INotifyCollectionChangedइंटरफेस प्रदान करती हैं। यह उन्हें आसानी से दृश्य में बंधे डेटा की अनुमति देता है। मॉडल वर्ग जो वस्तुओं के संग्रह का प्रतिनिधित्व करते हैं, आम तौर पर ObservableCollection<T>वर्ग से प्राप्त होते हैं ।

  • मॉडल कक्षाएं आमतौर पर IDataErrorInfoया तो INotifyDataErrorInfoइंटरफेस के माध्यम से डेटा सत्यापन और त्रुटि रिपोर्टिंग प्रदान करती हैं ।

  • मॉडल कक्षाएं आमतौर पर एक सेवा या रिपॉजिटरी के साथ संयोजन में उपयोग की जाती हैं जो डेटा एक्सेस और कैशिंग को एन्क्रिप्ट करती हैं।


17

मैंने इसे "सादे अंग्रेजी" के रूप में लिखा है जैसा कि मैं इस श्रृंखला में MVVM पर सोच सकता हूं । विशेष रूप से, यह आरेख संभवतः सबसे सरल, संक्षिप्त विवरण है।

कहा जा रहा है, मूल रूप से, "मॉडल" आपके डेटा या व्यावसायिक नियम हैं। यह वास्तव में यह नहीं पता होना चाहिए कि इसका उपयोग कैसे या कहां किया जा रहा है, और विशेषकर यह नहीं कि कौन सी तकनीक इसका उपयोग करने जा रही है। "मॉडल" एप्लिकेशन का मुख्य साहस है - और यह इस बारे में चिंता करने की आवश्यकता नहीं है कि क्या एप्लिकेशन WPF, सिल्वरलाइट, विंडोज फॉर्म, ASP.NET, आदि है - यह एक शुद्ध रूप में सिर्फ "खुद" है।

"व्यू" वह हिस्सा है जो पूरी तरह से तकनीक विशिष्ट है। MVVM में, आदर्श रूप में, दृश्य लगभग 100% XAML होना चाहिए, क्योंकि यह लचीलेपन के लिए कुछ भारी लाभ प्रदान करता है।

हालाँकि, कुछ ऐसा होना चाहिए जो मॉडल से जानकारी को किसी ऐसे रूप में अनुवादित करे जहाँ यह तकनीक द्वारा प्रयोग करने योग्य हो - यह वह जगह है जहाँ ViewModel चलन में आता है। उदाहरण के लिए, यह अक्सर उस विशिष्ट डेटा के लिए एक "ViewModel" में मॉडल कक्षाओं को "लपेटता" है जिसमें कमांड्स (रनिंग लॉजिक के लिए), इम्प्लीमेंट्स INotifyPropertyChanged(डेटा बाइंडिंग सपोर्ट के लिए), आदि शामिल हैं। यह वह पुल है जो मॉडल बनाता है दृश्य द्वारा प्रयोग करने योग्य।


ठीक है धन्यवाद। मैंने वस्तुओं के रूप में मॉडल के बारे में सोचा, और ViewModel वस्तुओं को संभालने के तरीकों के रूप में, जैसे कि एक दृश्य मॉडल "वस्तुओं" को समझने में सक्षम है। लेकिन मुझे बताया गया कि यह गलत है, कि ViewModel ही ऑब्जेक्ट हैं। मुझे लगता है कि यह वही है जो वास्तव में मुझे भ्रमित कर रहा है।
आरकेएम

@Rosie: मैं अपनी उद्धृत श्रृंखला के माध्यम से पढ़ने (या कम से कम स्किमिंग) पढ़ने की सलाह दूंगा। मैंने इसे विशेष रूप से लिखा है क्योंकि एमवीवीएम पर कुछ (लगभग नहीं) लेख हैं जो पहले से ही यह नहीं मानते हैं कि आप एमवीसी या एमवीपी आदि को समझते हैं, यह वास्तव में "कदम से कदम" संक्रमण है;)
रीड कोपसे

इस साकार ज़ोंबी-सूत्रण एक है थोड़ा ... आपका आरेख का कहना है कि वी एम "एप्लिकेशन-विशिष्ट राज्य शामिल हैं और तर्क " (मेरी emph)। क्या यह सुझाव देता है कि आपको लगता है कि वीएम में डेटा क्यूए तर्क हो सकता है / होना चाहिए? संबंधित RssWpfMVVM.csproj को अपने दो दृष्टिकोण में कोई स्पष्ट QA नहीं लगता है।
रफिन

1

MVVM का एक शानदार परिचय जेसन डोलिंगर के वीडियो में यहां देखा जा सकता है । जब मैं शुरू कर रहा था तो मैंने काफी समय तक वीडियो को अपने पास रखा, यह वास्तव में उपयोगी है।


1
लिंक मर चुका है
ibrahim mahrir

1
@ibrahimmahrir ~ मैंने काम करने वाले URL का लिंक अपडेट कर दिया है। मैं अब वीडियो डाउनलोड कर रहा हूं।
21 नवंबर को इंटेक्स एक्सएक्स

0

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

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