MVC - Model-View-Controller

MVP - Model-View-Presenter

MVVM - Model-View-ViewModel

MVW / MV* - Model-View-Whatever

Both MVP and MVVM are derivatives of MVC. The key difference between it and it’s derivatives [də'revətɪvz] 衍生物 is the dependency each layer has on other layers as well as how tightly bound they are to each other.
MVVM (Model View ViewModel) is an architectural pattern based on MVC and MVP, which attempts to more clearly separate the development of user-interfaces (UI) from that of the business logic and behaviour in an application. To this end, many implementations of this pattern make use of declarative data bindings to allow a separation of work on Views from other layers.

This facilitates UI and development work occurring almost simultaneously within the same codebase. UI developers write bindings to the ViewModel within their document markup (HTML), where the Model and ViewModel are maintained by developers working on the logic for the application.
MVC vs MVVM vs MVP. What a controversial[ˌkɑːntrə'vɜːrʃl]有争议的 topic that many developers can spend hours and hours debating and arguing about.

For several years +AngularJS was closer to MVC (or rather one of its client-side variants), but over time and thanks to many refactorings and api improvements, it's now closer to MVVM – the $scope object could be considered the ViewModel that is being decorated by a function that we call a Controller.

Being able to categorize a framework and put it into one of the MV* buckets has some advantages. It can help developers get more comfortable with its apis by making it easier to create a mental model 构思模型 that represents the application that is being built with the framework. It can also help to establish terminology that is used by developers.

Having said, I'd rather see developers build kick-ass (kick-ass 强大的,有进取心的,很好的,成功的) apps that are well-designed and follow separation of concerns, than see them waste time arguing about MV* nonsense. And for this reason, I hereby declare AngularJS to be MVW framework - Model-View-Whatever. Where Whatever stands for "whatever works for you".

Angular gives you a lot of flexibility to nicely separate presentation logic from business logic and presentation state. Please use it fuel your productivity and application maintainability rather than heated discussions about things that at the end of the day don't matter that much.

The MVVM pattern provides the following benefits:

  • It helps to have a better Separation of concerns.
  • It allows to replace the View with a new one without changing the ViewModel.
  • It allows to easily unit test View's logic as now it is in a normal class (the ViewModel).
  • It allows graphics designers to work in the View without touching any logic.

Layers and dependecies of the MVVM pattern

The following is the list of allowed and forbidden dependencies:

  1. The View's code behind should not reference the ViewModel. It is only allowed when calling DataContext's commands from View's events (but there are better ways of doing it without adding this dependency).
  2. The View cannot reference anything from the Model. Neither code behind nor Bindings can talk with Model objects, only ViewModel ones.
  3. The ViewModel should contain always a Model reference.
  4. It is completely forbiden that the Model knows anything from the ViewModel. That indicates a flawed design for sure.
  5. The ViewModel must not know anything from the View as one ViewModel can work with different Views.