model-view-controller - mvvm شرح




ما هو الفرق بين MVC و MVVM؟ (14)

هل هناك فرق بين نمط "نموذج تحكم العرض" القياسي ونموذج نموذج Microsoft / View / ViewModel؟


MVC / MVVM ليس خيارًا إما / أو .

ينمو النموذجان ، بطرق مختلفة ، في كل من ASP.Net و Silverlight / WPF.

بالنسبة لـ ASP.Net ، يتم استخدام MVVM لربط البيانات ثنائية الاتجاه داخل طرق العرض. هذا هو عادة تنفيذ جانب العميل (على سبيل المثال باستخدام Knockout.js). MVC من ناحية أخرى هي طريقة لفصل المخاوف على جانب الخادم .

بالنسبة لـ Silverlight و WPF ، فإن نمط MVVM أكثر شمولاً ويمكن أن يبدو وكأنه يعمل كبديل لـ MVC (أو أنماط أخرى من تنظيم البرامج في مسؤوليات منفصلة). كان أحد الافتراضات ، التي جاءت في كثير من الأحيان من هذا النمط ، هو أن ViewModel ببساطة استبدلت وحدة التحكم في MVC (كما لو كان يمكنك فقط استبدال VM لـ C في الاختصار وسيتم غفر جميع) ...

لا يحل برنامج ViewModel بالضرورة الحاجة إلى أجهزة تحكم منفصلة.

تكمن المشكلة في: أن تكون قابلة للاختبار بشكل مستقل * ، وخاصة قابلة لإعادة الاستخدام عند الحاجة ، فإن نموذج العرض ليس لديه فكرة عن العرض الذي يعرضه ، ولكن الأهم من ذلك هو عدم معرفة مصدر بياناته .

* ملاحظة: في الواقع ، تزيل وحدات التحكم معظم المنطق ، من ViewModel ، الذي يتطلب اختبار الوحدة. ثم تصبح VM حاوية غبية تتطلب القليل من الاختبار ، إن وجد. هذا أمر جيد لأن VM هو مجرد جسر ، بين المصمم والمبرمج ، لذلك يجب أن تبقى بسيطة.

حتى في MVVM ، ستحتوي وحدات التحكم عادةً على كل منطق المعالجة وتقرر البيانات التي سيتم عرضها في أي من المشاهدات باستخدام نماذج المشاهدة.

من ما رأيناه حتى الآن الفائدة الرئيسية لنمط ViewModel لإزالة كود من XAML code-behind لجعل XAML يعدل مهمة أكثر استقلالية . ما زلنا نخلق وحدات التحكم ، عند الحاجة ، للتحكم (لا يقصد التورية) المنطق العام لتطبيقاتنا.

المبادئ التوجيهية MVCVM الأساسية التي نتبعها هي:

  • تعرض المشاهدات شكلًا معينًا من البيانات . ليس لديهم أي فكرة عن مصدر البيانات.
  • يحتفظ ViewModels بشكل معين من البيانات والأوامر ، ولا يعرف مصدر البيانات أو الكود أو طريقة عرضه.
  • تحتفظ النماذج بالبيانات الفعلية (السياق المتنوع أو التخزين أو الطرق الأخرى)
  • يستمع المتحكمون إلى الأحداث وينشرونها. توفر أجهزة التحكم المنطق الذي يتحكم في البيانات التي يتم مشاهدتها وأين. توفر وحدات التحكم رمز الأمر إلى ViewModel بحيث يكون ViewModel قابلاً لإعادة الاستخدام بالفعل.

لاحظنا أيضًا أن إطار Generic Sculpture Sculpture ينفذ MVVM ونمطًا مشابهًا لـ Prism ، كما أنه يستخدم بشكل واسع وحدات التحكم لفصل كل منطق حالة الاستخدام.

لا تفترض أن وحدات التحكم أصبحت قديمة من خلال نماذج العرض.

لقد بدأت في إنشاء مدونة حول هذا الموضوع وسأضيفها إلى متى وأستطيع ذلك . هناك مشاكل في دمج MVCVM مع أنظمة الملاحة الشائعة ، لأن معظم أنظمة الملاحة تستخدم فقط المشاهدات و VMs ، لكنني سأدخل ذلك في مقالات لاحقة.

ومن المزايا الإضافية لاستخدام نموذج MVCVM هو أن كائنات وحدة التحكم فقط تحتاج إلى الوجود في الذاكرة لحياة التطبيق وأن وحدات التحكم تحتوي بشكل أساسي على الكود وبيانات الحالة الصغيرة (أي الذاكرة الصغيرة). وهذا يجعل التطبيقات التي تتطلب ذاكرة أقل بكثير من الحلول حيث يجب الإبقاء على نماذج المشاهدة وهي مثالية لأنواع معينة من تطوير الهاتف المحمول (مثل Windows Mobile باستخدام Silverlight / Prism / MEF). يعتمد هذا بالطبع على نوع التطبيق لأنك قد لا تزال بحاجة إلى الاحتفاظ بالـ VM مؤقتًا مؤقتًا للاستجابة.

ملاحظة: تم تحرير هذه المشاركة عدة مرات ، ولم تستهدف بالتحديد السؤال الضيق المطلوب ، لذلك قمت بتحديث الجزء الأول لتغطية ذلك أيضًا. جزء كبير من المناقشة ، في التعليقات أدناه ، يتعلق فقط بـ ASP.Net وليس بالصورة الأوسع. كان الغرض من هذه الوظيفة هو تغطية الاستخدام الأوسع لـ MVVM في Silverlight و WPF و ASP.Net ومحاولة تجنب الأشخاص الذين يستبدلون وحدات التحكم باستخدام ViewModels.


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.


أعتقد أن أسهل طريقة لفهم ما تعنيه هذه الاختصارات هو نسيانها للحظة. بدلاً من ذلك ، فكر في البرنامج الذي أنشأوه ، كل واحد منهم. انها حقا يتلخص فقط إلى الفرق بين شبكة الإنترنت المبكرة وسطح المكتب.

أول اختصار ، MVC ، نشأ على الويب. (نعم ، ربما كان موجودًا من قبل ، لكن الويب هو كيف تم تعميمها على جماهير مطوري الويب.) فكر في قاعدة البيانات وصفحات HTML ورمزًا في المنتصف. دعونا ننقح ذلك قليلاً للتوصل إلى MVC: For »database« ، لنفترض رمز قاعدة البيانات بالإضافة إلى الواجهة. ل »صفحات HTML« ، دعونا نفترض قوالب HTML بالإضافة إلى رمز معالجة القالب. بالنسبة لـ »كود interbetween« ، دعنا نفترض أن نقرات المستخدم تقوم بتعليمة الكود إلى أفعال ، ربما تؤثر على قاعدة البيانات ، وبالتأكيد تتسبب في عرض آخر. هذا كل شيء ، على الأقل لغرض هذه المقارنة.

دعونا نحتفظ بميزة واحدة من عناصر الويب هذه ، ليس كما هي اليوم ، ولكن كما كانت موجودة قبل عشر سنوات ، عندما كان جافا سكريبت مزعجًا ضعيفًا وقليلًا ، والذي فعله المبرمجون الحقيقيون بشكل جيد للتخلص من: صفحة HTML هي غبية وسلبية بشكل أساسي . المستعرض هو عميل رفيع ، أو إذا رغبت في ذلك ، عميل فقير. لا يوجد ذكاء في المتصفح. يعيد تحميل الصفحة بالكامل. يتم إنشاء "عرض" من جديد في كل مرة.

دعونا نتذكر أن هذه الطريقة على شبكة الإنترنت ، على الرغم من كونها جميع الغضب ، كانت متخلفة بشكل فظيع مقارنة بسطح المكتب. تطبيقات سطح المكتب هي عملاء الدهون ، أو العملاء الأغنياء ، إذا صح التعبير. (يمكن التفكير حتى في برنامج مثل مايكروسوفت وورد كما يأتي العميل ، العميل للمستندات). انهم عملاء كامل من الذكاء ، والكامل للمعرفة حول البيانات الخاصة بهم. انهم جليلون أنها مخزنة البيانات التي يتم التعامل معها في الذاكرة. لا حماقة مثل إعادة تحميل صفحة كاملة.

وهذه الطريقة المكتوبة الغنية هي على الأرجح المكان الثاني الذي نشأ فيه ، MVVM. لا تنخدع بالأحرف ، بحذف الـ C. لا يزال المتحكمون هناك. يجب أن يكونوا. لا شيء يحصل إزالتها. نحن نضيف فقط شيئًا واحدًا: حالة من الأهمية ، بيانات مخزنة مؤقتًا على العميل (ومعها معلومات استخباراتية للتعامل مع تلك البيانات). هذه البيانات ، في الأساس ذاكرة تخزين مؤقت على العميل ، أصبحت تسمى الآن »ViewModel«. هذا ما يسمح التفاعلية الغنية. وهذا كل شيء.

  • MVC = model ، controller ، view = اتصال أحادي الاتجاه بشكل أساسي = تفاعل ضعيف
  • MVVM = model، controller، cache، view = two-way communication = rich interactiveivity

يمكننا أن نرى أنه مع Flash ، Silverlight ، والأهم من ذلك - Javascript ، احتضنت شبكة الويب MVVM. لم يعد من الممكن أن يُطلق على المتصفحات عملاء شرعيون. انظر إلى قابليتها للبرمجة. انظر إلى استهلاك الذاكرة الخاصة بهم. انظر إلى كل تفاعلات جافا سكريبت على صفحات الويب الحديثة.

أنا شخصياً أجد هذه النظرية واختصارة الأعمال أسهل للفهم من خلال النظر إلى ما يشير إليه في الواقع الملموس. المفاهيم المستخلصة مفيدة ، خاصة عند إثباتها على المادة الملموسة ، لذا قد يأتي التفاهم في دائرة كاملة.


اختلاف بسيط: (مستوحى من دورة Yaakov's Coursera AngularJS)

MVC (وحدة تحكم عرض النموذج)

  1. الطرازات: تحتوي النماذج على معلومات البيانات. لا استدعاء أو استخدام المراقب المالي وعرض. يحتوي على منطق الأعمال وطرق تمثيل البيانات. قد يتم عرض بعض هذه البيانات ، بشكل ما ، في طريقة العرض. يمكن أن يحتوي أيضًا على منطق لاسترداد البيانات من بعض المصادر.
  2. وحدة التحكم: تعمل كصلة بين العرض والطراز. عرض المكالمات يستدعي جهاز التحكم ووحدة التحكم النموذج. وهي تقوم بشكل أساسي بإعلام النموذج و / أو وجهة نظر التغيير حسب الاقتضاء.
  3. عرض: يتعامل مع جزء واجهة المستخدم. يتفاعل مع المستخدم.

MVVM (نموذج عرض نموذج العرض)

ViewModel :

  1. إنه تمثيل حالة العرض.
  2. انها تحمل البيانات التي يتم عرضها في طريقة العرض.
  3. يستجيب لعرض الأحداث ، ويعرف أيضا باسم منطق العرض.
  4. يدعو وظائف أخرى لمعالجة منطق الأعمال.
  5. لا تطلب أبدًا من العرض عرض أي شيء.

لشيء واحد ، MVVM هو تطور لنمط MVC الذي يستخدم XAML للتعامل مع الشاشة. توضح هذه المقالة بعض جوانب الاثنين.

يبدو أن التوجه الرئيسي للعمارة النموذجية / View / ViewModel هو أنه في مقدمة البيانات ("النموذج") ، هناك طبقة أخرى من المكونات غير المرئية ("ViewModel") التي تقوم بتخطيط مفاهيم البيانات عن كثب إلى مفاهيم طريقة عرض البيانات ("العرض"). إنها ViewModel التي يربطها العرض ، وليس النموذج مباشرةً.


نموذج العرض هو نموذج "مجردة" لعناصر واجهة المستخدم الخاصة بك. يجب أن تسمح لك بتنفيذ الأوامر ، والإجراءات في طريقة العرض الخاصة بك بطريقة غير مرئية (على سبيل المثال لاختبارها).

إذا كنت قد عملت مع MVC ، فقد يكون من المفيد في بعض الأحيان إنشاء كائنات نموذج لتعكس حالة عرضك ، على سبيل المثال ، لإظهار وإخفاء مربع حوار التحرير ، وما إلى ذلك. في هذه الحالة ، أنت تستخدم نموذجًا للعرض.

نمط MVVM هو ببساطة تعميم هذه الممارسة على جميع عناصر واجهة المستخدم.

وهو ليس نمطًا من نماذج Microsoft ، ما يُلحِق أن عمليات ربط بيانات WPF / Silverlight مناسبة تمامًا للعمل مع هذا النمط. ولكن لا شيء يمنعك من استخدامه مع وجوه خادم جافا ، على سبيل المثال.


يمكنك رؤية شرح لنموذج MVVM في بيئة Windows:

في نموذج تصميم نموذج View-ViewModel ، يتألف التطبيق من ثلاثة مكونات عامة.

  • النموذج : يمثل نموذج البيانات الذي يستهلكه تطبيقك. على سبيل المثال ، في تطبيق مشاركة الصور ، قد تمثل هذه الطبقة مجموعة من الصور المتاحة على الجهاز و API المستخدم للقراءة والكتابة إلى مكتبة الصور.

  • عرض : يتألف أحد التطبيقات عادةً من صفحات متعددة من واجهة المستخدم. كل صفحة تظهر للمستخدم هي وجهة نظر في مصطلحات MVVM. طريقة العرض هي شفرة XAML المستخدمة لتحديد ما يراه المستخدم وتمييزه. يتم عرض البيانات من النموذج للمستخدم ، وهي مهمة ViewModel لإطعام واجهة المستخدم هذه البيانات استنادًا إلى الحالة الحالية للتطبيق. على سبيل المثال ، في تطبيق مشاركة الصور ، ستكون وجهات النظر هي واجهة المستخدم التي تعرض للمستخدم قائمة الألبومات الموجودة على الجهاز ، والصور الموجودة في الألبوم ، وربما الأخرى التي تعرض للمستخدم صورة معينة.

  • ViewModel : يربط ViewModel طراز البيانات ، أو ببساطة طراز ، إلى واجهة المستخدم ، أو طرق العرض ، للتطبيق. وهو يحتوي على المنطق الذي يتم من خلاله إدارة البيانات من النموذج وعرض البيانات كمجموعة من الخصائص التي يمكن ربط واجهة المستخدم XAML أو طرق العرض بها. على سبيل المثال ، في تطبيق مشاركة الصور ، سيعرض ViewModel قائمة من الألبومات ، وسيعرض كل ألبوم قائمة من الصور. واجهة المستخدم لا حصر لها من أين تأتي من الصور وكيف يتم استردادها. إنه يعرف ببساطة مجموعة من الصور كما تتعرض لها ViewModel ويعرضها للمستخدم.


MVVM Model-View MVVM يشبه MVC ، وحدة تحكم Model View

يتم استبدال وحدة تحكم مع ViewModel . يجلس ViewModel تحت طبقة واجهة المستخدم. يعرض ViewModel البيانات وكائنات الأوامر التي يحتاجها العرض. يمكنك أن تفكر في ذلك ككائن حاوية يتم عرضه للحصول على بياناته وإجراءاته. يسحب ViewModel بياناته من النموذج.

Russel East يقوم بمدونة تناقش بالتفصيل لماذا تختلف MVVM عن MVC


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.


From a practical point of view, MVC (Model-View-Controller) is a pattern. However, MVC when used as ASP.net MVC, when combined with Entity Framework (EF) and the "power tools" is a very powerful, partially automated approach for bringing databases, tables, and columns to a web-page, for either full CRUD operations or R (Retrieve or Read) operations only. At least as I used MVVM, the View Models interacted with models that depended upon business objects, which were in turn "hand-made" and after a lot of effort, one was lucky to get models as good as what EF gives one "out-of-the-box". From a practical programming point of view, MVC seems a good choice because it gives one lots of utility out-of-box, but there is still a potential for bells-and-whistles to be added.


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.


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.


mvc هو جانب الخادم و mvvm هو جانب العميل (المتصفح) في تطوير الويب.

يتم استخدام معظم javascript لل mvvm في المستعرض. هناك العديد من تقنيات جانب الخادم ل mvc.