model-view-controller - एमवीसी और एमवीवीएम के बीच क्या अंतर है?




design-patterns mvvm (17)

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

मानक "मॉडल व्यू कंट्रोलर" पैटर्न और माइक्रोसॉफ्ट के मॉडल / व्यू / व्यू मॉडेल पैटर्न के बीच कोई अंतर है?


Complementary to many of the responses given, I wanted to add some additional perspective from the Modern client-side web - or Rich Web Application point of view.

Indeed these days simple web sites and larger web applications are commonly built with many popular libraries such as Bootstrap. Built by Steve Sanderson, Knockout provides support for the MVVM pattern which mimics one of the most important behaviors in the pattern: data-binding through the View Model. With a little JavaScript, data and logic can be implemented that can then be added to page elements with simple data-bind HTML attributes, similar to using many of the features of Bootstrap . Together, these two libraries alone offer interactive content; and when combined with routing this approach can result in a simple-yet-powerful approach to building the Single Page Application .

Similarly, a Modern client-side framework such as Angular follows the MVC pattern by convention, but also adds a Service. Interestingly, it is touted as Model-View-Whatever (MVW). (See this post on .)

Additionally, with the rise of Progressive web frameworks such as Angular 2, we're seeing a change in terminology and perhaps a new architectural pattern where Components comprise of a View or Template and interact with a Service - all of which can be contained in a Module; and a series of Modules makes up the application.


I used to think that MVC and MVVM are the same. Now because of the existence of Flux I can tell the difference:

In MVC, for each view in your app, you have a model and a controller, so I would call it view, view model, view controller. The pattern does not tell you how one view can communicate with another. Therefore, in different frameworks there are different implementations for that. For example there are implementations where controllers talk to each other whereas in other implementations there's another component that mediates between them. There are even implementations in which the view models communicate with each other, which is a break of the MVC pattern because the view model should only be accessed by the view controller.

In MVVM, you also have a view model for each component. The pattern does not specify how the heck the view should influence the view model, so usually most frameworks just include controller's functionality in the view model. However, MVVM does tell you that your view model's data should come from the model, which is the entire model that's not aware or custom to a specific view.

To demonstrate the difference, let's take Flux pattern. Flux pattern tells how different views in the app should communicate. Each view listens to a store and fires actions using the dispatcher. The dispatcher in turn tells all the stores about the action that was just made, and the stores update themselves. A store in Flux corresponds to the (general) model in MVVM. it's not custom to any specific view. So usually when people use React and Flux, each React component actually implements the MVVM pattern. When an action occurs, the view model calls the dispatcher, and finally it's getting updated according to the changes in the store, which is the model. You can't say that each component implements MVC because in MVC only the controller can update the view model. So MVVM can work with Flux together (MVVM handles the communication between the view and the view model, and Flux handles the communication between different views), whereas MVC can't work with Flux without breaking a key principle.


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

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

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

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


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

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


सरल अंतर: (याकोव के Coursera AngularJS पाठ्यक्रम से प्रेरित)

एमवीसी (मॉडल व्यू कंट्रोलर)

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

एमवीवीएम (मॉडल व्यू व्यू मॉडल)

व्यू मॉडेल :

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

It surprises me that this is a highly voted answers without mentioning the origin of MVVM. MVVM is a popular term used in Microsoft community and it is originated from Martin Fowler's Presentation Model . So to understand the motive of the pattern and the differences with others, the original article about the pattern is the first thing to read.


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

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


Well, generally MVC is used in Web development and MVVM is most popular in WPF/Silverlight development. However, sometimes the web architecute might have a mix of MVC and MVVM.

For example: you might use knockout.js and in this case you will have MVVM on your client side. And your MVC's server side can also change. In the complex apps, nobody uses the pure Model. It might have a sense to use a ViewModel as a "Model" of MVC and your real Model basically will be a part of this VM. This gives you an extra abstraction layer.


MVVM मॉडल-व्यू व्यू मॉडेल एमवीसी, मॉडल-व्यू कंट्रोलर के समान है

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

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


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

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


Injecting Strongly Typed ViewModels into the View using MVC

  1. The controller is responsible for newing up the ViewModel and injecting it into the View. (for get requests)
  2. The ViewModel is the container for DataContext and view state such as the last selected item etc.
  3. The Model contains DB entities and is very close to the DB Schema it does the queries and filtering. (I like EF and LINQ for this)
  4. The Model should also consider repositories and or projection of results into strong types (EF has a great method... EF.Database.Select(querystring, parms) for direct ADO access to inject queries and get back strong types. This addresses the EF is slow argument. EF is NOT SLOW !
  5. The ViewModel gets the data and does the business rules and validation
  6. The controller on post back will cal the ViewModel Post method and wait for results.
  7. The controller will inject the newly updated Viewmodel to the View. The View uses only strong type binding .
  8. The view merely renders the data, and posts events back to the controller. (see examples below)
  9. MVC intercepts the inbound request and routes it to proper controller with strong data type

In this model there is no more HTTP level contact with the request or response objects as MSFT's MVC machine hides it from us.

In clarification of item 6 above (by request)...

Assume a ViewModel like this:

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!";
 }
}

The controller method of the post will look like this (See below), note that the instance of mvm is automatically instanciated by the MVC binding mechanisms. You never have to drop down to the query string layer as a result! This is MVC instantiating the ViewModel for you based on the query strings!

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

Note that in order for this actionmethod above to work as you intend, you must have a null CTOR defined that intializes things not returned in the post. The post back must also post back name/value pairs for those things which changed. If there are missing name/value pairs the MVC binding engine does the proper thing which is simply nothing! If this happens you might find yourself saying "I'm losing data on post backs"...

The advantage of this pattern is the ViewModel does all the "clutter" work interfacing to the Model/Buisness logic, the controller is merely a router of sorts. It is SOC in action.


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

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

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

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

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

  • एमवीसी = मॉडल, नियंत्रक, देखें = अनिवार्य रूप से एक तरफा संचार = खराब अंतःक्रियाशीलता
  • एमवीवीएम = मॉडल, नियंत्रक, कैश, देखें = दो तरफा संचार = समृद्ध अंतःक्रियाशीलता

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

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


एक बात के लिए, एमवीवीएम एमवीसी पैटर्न की प्रगति है जो प्रदर्शन को संभालने के लिए एक्सएएमएल का उपयोग करता है। यह आलेख दोनों के कुछ पहलुओं को रेखांकित करता है।

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


MVVMC, or perhaps MVC+, seems to be a viable approach for enterprise as well as rapid application development. While it is nice to separate the UI from business and interaction logic, the 'pure' MVVM pattern and most available examples work best on singular views.

Not sure about your designs, but most of my applications, however, contain pages and several (reusable) views and thus the ViewModels do need to interact to some degree. Using the page as controller would defeat the purpose of the MVVM altogether, so not using a "VM-C" approach for the underlying logic might result in .. well .. challenging constructs as the application matures. Even in VB-6 most of us probably stopped coding business logic into the Button event and started 'relaying' commands to a controller, right? I recently looked at many emerging framworks on that topic; my favorite clearly is the Magellan (at codeplex) approach. Happy coding!

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


एमवीसी / एमवीवीएम एक या / पसंद नहीं है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Too many people put objects which are not thread safe in a singleton pattern. I've seen examples of a DataContext ( LINQ to SQL ) done in a singleton pattern, despite the fact that the DataContext is not thread safe and is purely a unit-of-work object.