Mvc/mvp/mvvm

Architectural patterns of the article many, good understanding of not a few. The main issues that arise in most articles are:

• No scope is set: Front-end MVC is a modified MVC, and there is a clear difference between the background MVC and the generalize

• There are no practical examples: The actual example corresponds to the daily work, which is not very difficult to resonate with, thus causing the problem of seeing a forgotten once.

• No clear purpose: what is the real meaning of understanding architectural patterns? Virtual DOM and the location of the component in mv*?

The problem is too big, there must be negligence and wrong place, also welcome everyone to point out ~

1.1 Back-end MVC and front-end MVC

From the implementation, the main can be divided into the back-end MVC and front-end MVC two kinds. The differences between the two types of MVC are as follows:

It can be seen that the front-end MVC is actually to solve the problem of the front-end complex JS modularity, from the back-end MVC V-out of MVC, and back-end MVC does not have a direct relationship. in the front-end MVC, M occupies a very low proportion, referring only to data generation. The ratio of the back end V is very low, only the part of the template .

1.2 MVC/MVP/MVVM

It can be clearly seen that the difference between these three architectures is in the "M-V Link" section. Let's make a comparison for this section below:

• Controller: Monitor the user events of the view, get the data after the controller do some processing, and then render the view.

Of course, in some back-end MVC architectures, model can also directly render the view template, but this is only the implementation of different variants, here is not much discussion.

But at any time the complexity of logic, such processing encountered a difficult to debug problems. Because view must be run in the UI environment, and model or controller and view strong coupling, there is no way to verify the correctness of the application logic alone. When the problem arises, because each module is coupled together, it is not possible to quickly determine which module is the problem. As a result, the MVP model appears.

• Presenter: Compared to Controller,presenter, the interface provided by the view layer is invoked to render the model. There are several advantages to doing so:

• Interface-Oriented Programming

• Better decoupling

• Easy to do unit testing

Now that P and V are decoupled, p can do the unit test on its own. The software structure is divided into clearer, clearer logic and easy to debug. But all of this comes from a premise: The view layer provides an interface. When a UI is complex, the view layer needs to provide a lot of interfaces, which in itself is a cost of development debugging. So, Mvvm was born.

• ViewModel: Compared to MVP, view needs to provide API,MVVM to build a set of state data in the VM as an abstraction of the view state. The state data in the VM is then aligned with the display state in the view (screen) with two-way data binding. In this way, the presentation logic in the VM only needs to modify the corresponding state data to control the state of the view, thus avoiding the development of a large number of interfaces on the view.

Are there any drawbacks to VMS? Some, when the UI is relatively simple, the use of VMS will complicate business logic, there is a suspicion of excessive design. So VMs are only suitable for projects with complex UI interactions.

2. An example

Example: Now the user drop down to refresh a page, there are 10 new news on the page, the total number of news from 10 into 20. Then the MVC, MVP, and MVVM processes are:

View get drop-down event, notify Controller
2. Controller back to the model to initiate the request, the request content is a drop-down refresh
3. Model obtains 10 news data, passes to controller
4. Controller get 10 News data, may do some data processing, and then take the processed data to render View
MVC: Get UI node, render 10 News MVP: render 10 News MVVM with view-provided interface : No action required, as long as VM data changes, bidirectional binding via data,view changes directly  

3. Understanding the meaning of architecture

The big point is to think in terms of the creator and why they are so designed, and what good it does. Of course, it also helps us to understand other relevant knowledge. By the time of the future, when we are confronted with more complex situations and cannot be solved with today's MVVM, we can follow this thinking context, re-design the architecture, and emit our own light.

Note: Virtual DOM and component

Whether it's virtual DOM or component, it's a development strategy, not a question of architectural patterns. In other words, they and mv* are things in two dimensions. So it doesn't make sense to pull virtual dom and component into the MVC,MVP,MVVM difference.

Mvc/mvp/mvvm