फिर भी एक और एमवीवीएम प्रश्न ... क्या मेरी समझ सही है?

Question

क्षमा करें अगर यह एक डुप्लिकेट है, तो यह इतना नहीं है कि 'एमवीवीएम क्या है', बल्कि, 'क्या यह एमवीवीएम' है, मैंने काफी पढ़ा है, और मुझे लगता है कि मुझे इसकी मूल समझ है कि यह क्या है , मुझे अपना खुद का 'एक-लाइनर' मिला है, इस तरह, मैं इसे कैसे समझता हूं, लेकिन यह सुनिश्चित करना चाहता हूं कि मैं इसे अपने सिर में दृढ़ता से शामिल करने से पहले सही हूं,

अनिवार्य रूप से; मॉडल शुद्ध डेटा है - कोई तरीका नहीं, प्रति मॉडल एक व्यू मॉडेल है, इसमें मॉडल का संदर्भ है - यह मॉडल डेटा में सभी परिवर्तन करता है और आखिरकार व्यू में एक (या अधिक) व्यूमोडेल संदर्भ और प्रारूप होगा & ViewModel द्वारा प्रदान किए गए डेटा को प्रदर्शित करें।

(नहीं के बाद ट्यूटोरियल के लिए लिंक, ब्लॉग्स आदि, बस एक हाँ, या तोड़ मरोड़ के साथ कोई ठीक हो जाएगा, जैसा कि मैंने फिर से पढ़ने के लिए सब कुछ फिर से वैसे भी अगर नहीं :) होगा)

Answer 1

पूरी तरह से नहीं - कम से कम, जैसा कि मैं इसे पूरी तरह से परिभाषित नहीं करता हूं।

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

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

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

व्यक्तिगत रूप से, मैं "एक व्यू मॉडेल प्रति व्यू" के संदर्भ में सोचना पसंद करता हूं, क्योंकि व्यूमोडेल एक या अधिक मॉडल को अनुकूलित रूप से किसी दिए गए दृश्य के साथ काम करने के लिए अनुकूलित कर सकता है, लेकिन फिर भी, कभी-कभी यह एक स्वैप करने में सहायक होता है सामग्री बदलने के लिए एक ही दृश्य के भीतर ViewModel।

Answer 2

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

मुझे लगता है कि सबसे अच्छा रवैया अपना सर्वश्रेष्ठ करना है, फिर बाकी दस्तावेज करें। बहुत शुद्धता पसीना मत करो।

Answer 3

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

Answer 4

बंद करें, लेकिन काफी नहीं। यहाँ कुछ अंक हैं कि तुम्हारा से अलग हो रहे हैं:

1. मॉडल उन पर तरीकों हो सकता है। वे सिर्फ डेटा नहीं हैं। उनके पास "पुनर्प्राप्ति", "स्टोर" इत्यादि जैसी विधियां हो सकती हैं। व्यवसाय तर्क कोड। अज्ञेयवादी देखें।

2. इस पर कोई प्रतिबंध नहीं है कि मॉडल के संदर्भ में कितने व्यूमोडल्स हैं। ViewModels व्यू-स्तरीय व्यवहार को समाहित करता है, इसलिए आपके पास एक ही मॉडल के लिए व्यवहार के कई अलग-अलग सेट हो सकते हैं। उदाहरण के लिए, एक व्यूमोडेल मॉडल आइटम का केवल-पढ़ने वाला परिवर्तन हो सकता है। एक अन्य मॉडल आइटम पर पढ़ने/लिखने के फॉर्म सत्यापन प्रदान कर सकता है।

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

Answer 5

यहां बहुत सारी जानकारी है, और मुझे लगता है कि इनमें से अधिकतर उत्तर सही हैं। मुझे नहीं लगता कि कोई 1 विशिष्ट परिभाषा है, न ही इस मामले पर 1 विशिष्ट प्राधिकरण है। यहां तक ​​कि माइक्रोसॉफ्ट के पास वास्तव में स्पष्ट परिभाषा नहीं है।

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

मेरी राय में पूरे पैटर्न का लाभ आपको मॉड्यूलर, स्वीकार्य भागों के साथ आवेदन करने के लिए संभव है जितना संभव हो उतना कम निर्भरता के साथ।

यह मेरे दिमाग में एक वास्तविक गायब हिस्सा है, क्योंकि यह एमवीसी पैटर्न में अलग नियंत्रक तर्क से प्राप्त लाभ/कार्यों को प्रदान करता है।

Answer 6

आपकी समझ गलत है। आपके पास कई मॉडल हो सकते हैं और उनमें से सभी के पास अपना स्वयं का दृश्य हो सकता है और फिर एकल व्यूमोडेल का हिस्सा बन सकता है। उदाहरण: आपके पास मॉडल हैं: उत्पाद, ग्राहक उनमें से प्रत्येक का अपना कस्टम दृश्य कस्टम नियंत्रण के रूप में दर्शाया गया है और आपके पास एक व्यूमोडेल है जो आपके सभी मॉडलों को जोड़ता है और अंत में आपके ऐप की विंडो पर आप सभी को अपने दृश्यों को जोड़ते हैं जो आपके मॉडल से आपके व्यूमोडेल

Answer 7

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

---

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

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

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

---

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

यदि आप कभी भी ऐसा करते हैं: "text1.text = value" आप इसे गलत कर रहे हैं। यदि आप कभी भी कमांड हैंडलर लिखते हैं जो "my.ViewModel.SomeCommand" कहता है तो आप इसे गलत कर रहे हैं।