एमवीसी

Question

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

क्या कोई बता सकता है कि क्यों एमवीसी उपयुक्त नहीं है और क्यों एमवीवीएम सिल्वरलाइट विकास के लिए बेहतर है?

धन्यवाद जद

Answer 1

इसका एक बहुत ही पतला अंतर है, जो मैं WPF में ASP.NET और MVVM में MVC की तुलना द्वारा सबसे अच्छा व्याख्या कर सकते हैं।

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

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

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

Answer 2

मुझे लगता है कि विचार यह है कि एमवीवीएम बेहतर एमवीसी की तुलना में एक्सएएमएल के अनुकूल है। एमवीसी कह रहा है 'अनुकूल नहीं है' थोड़ा अतिरंजित है।

और एमवीवीएम बेहतर क्यों है? मुख्य रूप से XAML में शानदार डेटा-बाध्यकारी और कमांड-बाइंडिंग की वजह से। this article देखें।

Answer 3

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

सबसे अच्छा दो लेख मैं आए हैं भर में है कि मुझे सिद्धांतों को समझने में मदद मिली MVC vs MVP vs MVVM और MVVM for Tarded Folks Like Me or MVVM and What it Means to Me

Answer 4

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

Answer 5

Decoupling अवयव

MVC में, आप घटकों के बीच एक त्रिकोणीय रिश्ता है। यही है: नियंत्रक दृश्य और मॉडल का मालिक है। दृश्य मॉडल की परिभाषा पर निर्भर करता है। मॉडल को दृश्य की आवश्यकताओं को पूरा करने की आवश्यकता है।एक हब (नियंत्रक) और बोलने वाले आर्किटेक्चर (देखें और मॉडल) के बारे में सोचें

एमवीवीएम में, उस त्रिभुज के बारे में सोचें कि प्रत्येक घटक के साथ केवल श्रृंखला में एक दूसरे के बारे में जानना है। यह है: देखें-> ViewModel-> मॉडल

मॉडल स्टैक पर कुछ भी अनजान है। व्यूमोडेल केवल मॉडल के बारे में अवगत है, व्यू केवल मॉडल के बारे में जागरूक है - यह मॉडल से अनजान है।

यह महत्वपूर्ण क्यों है?

यह मूल प्रश्न का मूल है।

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

इसे पूरी तरह से समझने के लिए, यह समझने में मददगार है कि घटक वास्तव में क्या प्रतिनिधित्व करते हैं। व्यू, कंट्रोलर, व्यू मॉडेल या मॉडल क्या है? क्या वे शाब्दिक परिभाषाएं हैं, या एक अमूर्त अवधारणा के अधिक हैं?

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

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

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

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

अपने निर्भरता बाहर सपाट

MVVM निर्भरता बाहर सपाट। यह फोकस बनाता है। फोकस क्या है? अन्य सभी निर्भरताओं के व्याकुलता के बिना कार्यक्षमता के एक टुकड़े पर काम करने की क्षमता। अब आप कोड पर यूनिट परीक्षण लिखना शुरू कर सकते हैं जिसे पहले अवांछित समझा जाता था।

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

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

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

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

Testability testability पर

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