We front-end programmers have never used MVC or MVP before. But it just reflects the front-end these years from nothing to have, from have to excellent change process, so along this train of thought answer will be very clear.

“Age

  • In the web1.0 era, there was no concept of a front end. Develop a web application written by ASP.NET/Java/PHP, the project is usually composed of multiple aspx/ JSP /PHP files, each file contains HTML, CSS, Javascript, C#/Java/PHP code, The overall architecture of the system might look like this:

The advantage of this architecture is simplicity and speed, but the disadvantage is also obvious: JSP code is difficult to maintain.

  • In order to make the development more convenient, the code is easier to maintain, and the responsibilities of the front and back end are clearer. MVC development pattern and framework were derived, and the front-end display appeared in the form of templates. Typical frameworks are Spring, Structs and Hibernate. The overall framework is shown in the figure:

With this layered architecture, responsibilities are clear and code is easy to maintain. But the MVC here is limited to the back end, there is some separation between the front and back ends, and the front end only completes the view layer in the back end development.

However, some of the same patterns exist:

1. The front-end page development efficiency is not high; 2. The responsibilities of the front and back ends are unclearCopy the code

Web2.0 era

  • Since the advent of Gmail, Ajax technology has taken over the world. With Ajax, the responsibilities of the front and back end are much clearer. Because the front end can interact with the back end through Ajax, the overall architecture diagram also changes to the following diagram:

Through Ajax and background server data exchange, front-end developers, only need to develop the page this part of the content, data can be provided by the background. Ajax can also partially refresh pages, reducing server load and traffic consumption, and improving user experience. At this time, there began to be full-time front-end engineers. At the same time, the front-end class libraries are slowly developing, the most famous being jQuery. Of course, there are problems with this architecture: there is no viable development model to accommodate more complex business needs, and the page content is all mixed up, which becomes difficult to maintain once the application scale increases. Hence the MVC of the front end.

Architecture evolution after the separation of the front and back ends– the MVC,MVP 和 MVVM

MVC

  • The FRONT-END MVC is similar to the back-end, with View, Controller and Model.
    • Model: Saves application data and synchronizes it with back-end data.
    • Controller: Responsible for the business logic that modifies Model data based on user behavior.
    • View: Responsible for View display and visualization of data in Model.

The three form a model like the one shown here:

Such a model, in theory, is feasible. But often in real development, this is not how it works. Because the development process is not flexible. For example, if a small event operation has to go through such a process, then development is no longer convenient.

In a real scenario, we tend to see another pattern, as shown below:

This mode is more flexible in development, backbone.js framework is this mode.

However, this flexibility can lead to serious problems:

  1. Data flow is chaotic. The diagram below:

  1. View is big and Controller is thin: Because many developers write logic code in View, gradually the content in View gets bigger and the Controller gets thinner and thinner.

Where there are defects, there will be changes. The reason the MVP model seems to be missing from the front end is that AngularJS brought the MVVM framework model to the front end early. The MVP model, while not very common in front end development, is still considered in native android development.

MVP

  • MVP is close to MVC. The P stands for Presenter, a middleman who is responsible for the flow of data between the View and the Model and prevents the View from communicating directly with the Model. We can take a look at the diagram:

As you can see, the Presenter is responsible for bidirectional interaction with the Model and bidirectional interaction with the View. This interaction is a little less flexible than MVC, the VIew becomes a passive VIew, and it becomes small. Although it separates the View from the Model. But as applications get bigger, they become larger and harder to maintain. The answer to this problem may be found in the thinking of MVVM.

MVVM

  • First, what is MVVM? MVVM can be decomposed into (model-view-viewModel). ViewModel can be thought of as an advanced version of presenter. As shown in the figure:

ViewModel automatically responds to data changes in Model by implementing a set of data response mechanism; And the Viewmodel implements an update strategy that automatically translates data changes into view updates; Modify the data in the Model in response to user interaction in the View through event listening. This saves a lot of DOM manipulation code in the ViewModel. MVVM keeps the View and Model loosely coupled while reducing the amount of code that maintains their relationship, allowing users to focus on business logic while balancing development efficiency and maintainability.

conclusion

  • All three are framework patterns designed to solve the problem of coupling Model and View.
  • MVC pattern appeared earlier and was mainly applied in the back end, such as Spring MVC, ASP.NET MVC, etc. It was also applied in the early front-end field, such as backbone.js. Its advantages are clear layering, while its disadvantages are data flow chaos and maintenance problems caused by flexibility.
  • MVP mode is an evolutionary form of MVC. Presenter, as the middle layer, is responsible for MV communication, which solves the coupling problem between the two. However, the bloated P layer will lead to maintenance problems.
  • MVVM mode is widely used in the front-end field. It not only solves the MV coupling problem, but also solves the maintenance of a large number of complex codes and DOM operation codes. It improves the development efficiency and readability while maintaining superior performance.