Go MVC, MVP, MVVM

Under the interface: Restore real MVC, MVP, MVVM patterns

[Date: 2015-10-28]

Source: Github.com/livoras Dai Jiahua

[Font: Big Small]

Objective

Doing client-side development, front-end development for MVC, MVP, MVVM these nouns do not understand and should be generally heard, are to solve the graphical interface application complexity management problems arising from the application architecture pattern. Many articles on the web on this aspect of the discussion is messy, the differences between the various mv* models are unclear, and even some of the descriptions are wrong. This article is traced back to the most classic Smalltalk-80 MVC pattern to gradually restore the most realistic mv* mode under the graphical interface.

GUI programs are facing the problem

The graphical interface of the application provides the user with a visual interface, which provides data and information. User input behavior (keyboard, mouse, etc.) executes some business logic that may result in changes to the application data, and changes in the data naturally require synchronized changes in the user interface to provide the most accurate information. For example, a user reordering a spreadsheet requires the application to respond to user actions, sort the data, and then synchronize to the interface.

When developing applications, to better manage the complexity of the application, the idea of separation of duties (speration of duties) will be layered on the application. When developing a graphical interface application, the hierarchy of the management user interface is called the view, and the application data is model (note that the model here refers to the domain model, which abstracts the data for the problem to be solved, does not contain the state of the application, Can be easily understood as an object). The model layer is ignorant of the business logic of the application, preserving only data structures and interfaces that provide data manipulation.

With view and model layering, there are two questions:

1. Management of business logic (such as sorting) that responds to user actions.
2. View how to synchronize the model changes.

Starting with these two questions and exploring the mv* pattern, you will find that the differences between these patterns can be summed up in different ways of dealing with the two problems. And almost all of the mv* models are classic SMALLTALK-80 MVC's modified version.

Smalltalk-80 MVC Historical Background

As early as the 70 's, American Xerox engineers developed the Smalltalk programming language and began using it to write applications for graphical interfaces. In this version of Smalltalk-80, an engineer named Trygve Reenskaug designed the architecture pattern of the MVC graphics application, greatly reducing the difficulty of managing the graphics application. In the four Otonin (GoF) design pattern, MVC is not considered as a design pattern, but simply as a collection of some of the classes that solve the problem. MVC, described by Smalltalk-80 MVC and Gof, is the most classic MVC pattern.

The dependency relationship of MVC

MVC puts the application into the view, the model layer, and the additional controller layer, whose job is to specifically manage the business logic of the application. The three levels of Model, View, controller dependencies are as follows:

Controller and view are dependent on the model layer, and controller and view can depend on each other. In some online data controller and view dependencies may not be the same, some are one-way dependencies, some are two-way dependence, this is not a small relationship, the latter will see their dependencies are to deal with user behavior triggered by the processing of business logic to the controller.

Call Relationships for MVC

After the user's view operation, the view captures this operation, which moves the right of processing to the controller (Pass calls), and the controller then executes the relevant business logic, which may require appropriate operation of the model When the model is changed, the Observer pattern is notified by the View;view that the model change is received through the Observer pattern , the latest data is requested from the model, and the interface is re-updated. Such as:

There seems to be no special place, but there are several key points that need special attention:

1. View is the transfer of control to the controller, which does not execute the business logic itself.
2. The controller executes the business logic and operates the model, but does not directly manipulate the view, which can be said to be ignorant of view.
3. The synchronization of the view and model is done through the Observer pattern , and the synchronization is done by the view itself requesting the model's data and then updating the image.

It is important to note that the essence of the MVC pattern is the 3rd: The model update is communicated to the view through the observer pattern, which can be either pub/sub or triggering Events. Many of the online descriptions of MVC do not emphasize this point. The benefit of the observer pattern is that different MVC triangles may have a common model, and a controller in an MVC triangle operates the model, and the two MVC Triangle view will receive notifications and then update itself. Maintains the real-time and accuracy of different view display data depending on the same model. The Observer pattern we use every day has been integrated into the MVC architecture by the great gods decades ago.

Here is a JavaScript Demo of the MVC pattern that implements a small todolist application. The classic Smalltalk-80 MVC can be implemented without any framework support. At present, only one of the Web front-end framework claims to strictly follow the Smalltalk-80 MVC pattern: maria.js.

The pros and cons of MVC

Advantages :

1. Separate the business logic into the controller, with a high degree of modularity. When the business logic changes, there is no need to change the view and model, only the controller will be replaced by another controller (swappable controller).
2. The Observer pattern can be updated at the same time as multiple views.

Disadvantages :

1. Controller testing is difficult. Because view synchronization operations are performed by the view itself, view can only be run in a UI-only environment. The correctness of the controller's business logic cannot be verified when the controller is unit tested without a UI environment: when the controller updates the model, the update operation of the view cannot be asserted.
2. View cannot be modular. View is strongly dependent on a particular model, and it is difficult to extract the view as a reusable component of another application. Because the domain model of different programs is not the same

MVC Model 2

The MVC pattern is also exposed to Web server development, which is not strictly called the MVC pattern. The classic MVC pattern only solves problems with client-side graphical interface applications, but not on the server. The MVC model of the server has its own specific name: MVC Model 2, or JSP Model 2, or the Model 2 directly. The interactive mode of the Model 2 client server is as follows:

The service receives the request from the client, the server passes the request to the specific controller through the routing rule, the controller executes the corresponding business logic, operates the database data (model), and then renders the specific template with the data and returns it to the client.

Because the HTTP protocol is a simplex protocol and is stateless, the server cannot push data directly to the client. The server-side model changes cannot be communicated to the client unless the client initiates the request again. So you can see that the classic Smalltalk-80 MVC model tells the view update through the Observer pattern that this ring is ruthlessly broken and cannot be called a strict MVC.

The Model 2 pattern was first applied to JSP applications in 1998, and the confusion of JSP Model 1 application management induced JSP to refer to the client MVC model, which spawned the Model 2.

This pattern was later applied in almost all language web development frameworks. PHP's Thinkphp,python Dijango, Flask,nodejs Express,ruby Ror, basically adopted this model. The usual MVC is basically this kind of server-side MVC.

Mvp

There are two types of MVP models:

1. Passive View
2. Supervising Controller

In most cases, the passive view mode is discussed. In this article, the PV mode is described in more detail, while the SC mode is simply mentioned.

Historical background

MVP mode is an improvement of the MVC pattern. In the 90 's, IBM's subsidiary, Taligent, developed a graphical interface application system called Commonpoint in C/

MVP (Passive View) dependencies

The MVP mode replaces the controller in the MVC pattern with presenter. The dependencies between MVP levels are as follows:

The MVP broke the view's original dependence on model, and the rest of the dependencies were consistent with the MVC pattern.

The call relationship of MVP (Passive View)

Since the view's dependence on model has been broken, how does the view synchronize model changes? Look at the MVP call relationship:

As with the MVC pattern, user actions on view are moved from view to presenter. Presenter also executes the corresponding business logic and operates on the model, while the model passes the message of its own change through the observer pattern, but is passed to presenter instead of view. Presenter gets the message to the model change, updates the interface through the interface provided by the view .

Key points:

1. View is no longer responsible for the logic of synchronization, but presenter. There are both business logic and synchronization logic in presenter.
2. The view needs to provide an interface for presenter to call. Key

In the MVC, the controller is not able to manipulate the view, and the view does not provide the corresponding interface, while in the MVP, presenter can operate View,view need to provide a set of interface operation interface to presenter to call The model still broadcasts its own changes through events, but is monitored by presenter instead of view.

MVP mode, which also provides an example written in JavaScript.

The pros and cons of MVP (Passive View)

Advantages:

1. Easy to test. Presenter to view is done through the interface, when the presenter is not dependent on the UI environment of the unit test. You can mock a view object, which simply implements the view's interface. Then the dependency is injected into the presenter, and the unit test can test the correctness of the presenter business logic completely. Here is a sample of the unit test for presenter, based on the above example.
2. View can be modular. In MVP, view does not rely on model. This allows view to be detached from a particular business scenario, so that view can be completely ignorant of the business logic. It only needs to provide a series of interfaces for upper-level operations. So you can do??? A highly reusable view component.

Disadvantages:

1. Presenter in addition to business logic, there are a large number of View->model,model->view manual synchronization logic, resulting in presenter cumbersome, maintenance will be more difficult.

MVP (supervising Controller)

It says MVP's passive view mode, which is very passive, and it knows almost nothing about it, presenter what it does. In the supervising Controller mode, presenter will give a part of the simple synchronization logic to the view to do, presenter is only responsible for the more complex, high-level UI operation, so it can be seen as a supervising Controller.

Dependency and invocation relationships in supervising Controller mode:

Since the supervising controller is used less, the discussion on it is here.

MVVM

MVVM can be seen as a special MVP (Passive View) mode, or an improvement to the MVP model.

Historical background

The MVVM pattern was first presented by Microsoft Corporation and was heavily used in. NET in WPF and Sliverlight. In 2005, Microsoft engineer John Gossman unveiled the MVVM pattern for the first time on his blog.

ViewModel

MVVM stands for Model-view-viewmodel, and here's what you need to explain about ViewModel. The meaning of ViewModel is "model of view", which is modeled on the view. Its meaning includes the domain model and the state of the view. In a graphical interface application, the information provided by the interface may include more than just the domain model of the application. It may also contain view states that are not included in the domain model, such as whether the spreadsheet program needs to display the status of the current sort in sequential or reverse order, which is not included in the domain models, but is also information that needs to be displayed.

You can simply interpret ViewModel as the data abstraction for what is displayed on the page, and unlike the domain model, ViewModel is more appropriate to describe the view.

The dependency of MVVM

The dependency and MVP dependence of MVVM is simply replacing P with a VM.

The invocation relationship of MVVM

MVVM has the same invocation relationship as the MVP. However, there will be something called binder, or data-binding engine, in the ViewModel. The data synchronization between view and model, previously owned by presenter, is referred to binder for processing. You only need to declare in the template syntax of the view that the content displayed on the view is bound to the data of the model. When viewmodel the model update, Binder automatically updates the data to the view, and when the user operates on the view (such as form input), Binder automatically updates the data to the model. This approach is called: Two-way data-binding, bidirectional data binding. Can be easily and inappropriately understood as a template engine, but will be rendered in real time based on data changes.

In other words, MVVM automates the synchronization logic of view and model. Previously presenter-Responsible view and model synchronizations are no longer manually operated, but are entrusted to the binder provided by the framework. Just tell Binder,view what part of the model is displayed.

Here's an example of JavaScript MVVM, because MVVM needs a binder engine. So the example uses an MVVM library: Vue.js.

The pros and cons of MVVM

Advantages :

1. Improved maintainability. It solves the problem of MVP's manual view and model synchronization, and provides a bidirectional binding mechanism. Improves the maintainability of the code.
2. Simplify testing. Because the synchronization logic is done by binder, the view is changed at the same time as the model, so just make sure the model is correct and the view is right. Significantly reduces the testing of view synchronization updates.

Disadvantages :

1. The simplistic graphical interface does not apply, or says Sledgehammer kills chickens.
2. For large graphics applications, the view state is high, and the cost of building and maintaining ViewModel is higher.
3. The declaration of data binding is written in the template of the view, which is not able to break the point of Debug.

Conclusion

As you can see, from MVC->MVP->MVVM, it's like a weird escalation process. The latter solves the problems left by the former, and optimizes the disadvantages of the former as the advantages. The same demo function, the code from the beginning of the stack of files, optimized to the last only need 20 lines of code to complete. mv* pattern between the distinction is quite clear, hope can give these patterns to understand the more vague students bring some reference and ideas.

Reference

• Scaling isomorphic Javascript Code
• Smalltalk-80 MVC
• Learning JavaScript Design Patterns
• Smalltalk-80 MVC in JavaScript
• GUI architectures
• The Model-view-presenter (MVP) Pattern

This article permanently updates the link address : http://www.linuxidc.com/Linux/2015-10/124622.htm

Go MVC, MVP, MVVM