"Turn" understanding of MVC, MVP, MVVM

"Turn" understanding of MVC, MVP, MVVM

Reprint Address: http://www.myexception.cn/vc-mfc/1612241.html

Understanding of MVC, MVP, MVVM

Recently read a bunch of JS framework documents, a bit messy, want to sort out, but first need to figure out these frameworks often talk about the concept of mv*. The concept of MVC has long been known, and now there are MVP, MVVM, so what is the difference between these design patterns? Talk about your own understanding.

When I first started to understand these concepts, I thought that although the models were all decoupled from the view and model, there was no relationship between them, and an application would only use one pattern. Then slowly found that the world is definitely not only black and white on both sides, the largest piece of the middle is actually a gray area, the same, the boundaries of these patterns are not so obvious, you may use in your own applications. In fact, there is no need to struggle with their own use is MVC, MVP or MVVP, regardless of black cat white cat, catch mouse is a good cat.

Mvc:model-view-controller
Mvp:model-view-presenter
Mvvm:model-view-viewmodel
Let's talk about the common denominator of the three, which is model and view.

1. Model is a domain model, a data object, and an interface that provides external operations on application data, and may also issue change notifications when data changes. Model does not depend on the implementation of the view, as long as the external program calls the model interface can be implemented to delete the data and other changes.
2. View is the UI layer that provides interactive functionality to the end user, including UI presentation code and some related interface logic code.

The difference between the three is how to bond the view and model, to achieve user interaction and change notification

1. The controller receives the operation events of the view, depending on the event, or invokes the model's interface for data manipulation, or a view jump, which also means that a controller can correspond to multiple view. Controller for the implementation of the view is not very concerned about, will only passively receive, model data changes are not directly informed by the Controller view, usually the view using observer mode to monitor the model changes.
2. Presenter, like a controller, receives the command of a View, operates on the model, and unlike a controller, the change notification that Presenter reacts to View,model is first obtained by Presenter. Then presenter to update the view. A presenter corresponds to only one view. Depending on the degree to which logical code is shared between presenter and view, there are two scenarios for this pattern: Passive View and Supervisor Controller.
3. ViewModel, note that the "model" here refers to the model of the view, which is not the same as the model above. The so-called view model is the one that contains some of the data properties and operations of the view, the key technology of this mode is data binding, the change of view will directly affect the ViewModel, ViewModel changes or content will be reflected directly on the view. This model is actually a framework for the application developers to do some work, developers only need less code to achieve more complex interaction.

MVP and MVVM completely isolate the model and view, but in some cases the copy of the data from model to ViewModel or presenter is expensive, and may also be combined with MVC, which can be directly notified to the view for changes. In the actual application it is very likely that you have unconsciously merged several patterns together, but in order to code scalability, testability, you must do the decoupling of the module, irrelevant code does not put together. I remember a few years ago in the last company to do a new product, an outsourcing company's new staff directly in view to do the database persistence, and a hibernate code to find that there are hundreds of rows of SQL statements, make us surprised, for a moment to become a joke.

Personally, when talking about the MVC architecture in a broad sense, it does not refer to the strictly defined MVC in this article, but rather to the mv*, which is the separation of views and models, as long as a framework provides the functionality of view and model separation, which we can consider to be an MVC framework. After development, you can see whether the framework is MVC, MVP, or MVVM.

If there is any mistake above, please point out, thank you.

Resources:

http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/

http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/