Reference article: Vernacular MVC, MVP, MVVP

Reference article: Diagrams of MVC, MVP, and MVVM

preface

Complex software must have a clear and reasonable architecture, otherwise it cannot be developed and maintained. Can you imagine if you had almost all the code of a piece of software in one file? A file with tens of thousands of lines, how do you let later personnel develop maintenance?

Model-view-controller (MVC) is one of the most common software architectures, which is widely used in the industry. It’s easy to understand on its own. It is also different from the derivative MVP and MVVM architectures.

MVC

The main idea of MVC is layering, no more hodgepodge. The MVC pattern means that software can be divided into three parts:

  • View: The user interface that controls the page.
  • Controller: Business logic that takes user input, operates on M and V, or simply calls methods in M and V.
  • Model: Used specifically to do some logic related to the data (add, delete, modify).

MVC interaction

As for the specific relationship between them, it depends on your specific code representation, there is no written definition, the most common is this:

All communication is one-way:

  • View: Receives user instructions and passes them to Controller.

  • Controller: After completing the service logic, the Model is required to change the state.

  • Model: New data is sent to the View and the user gets feedback.

But MVC, when used on a really large scale, comes closest to this:

That is, if you don’t have to deal with complex logic or data, some simple logic will be handled directly by the Controller, and then the Controller will act on the View. The other thing about MVC is that the View can communicate directly with the Model.

MVP

If you cut the relationship between the Model and the View, it becomes the MVP. MVP mode changes the name of Controller to Presenter and changes the direction of communication.

  • The communication between the parts is two-way.

  • The View and the Model are not connected to each other, but are passed by a Presenter.

  • A View is very thin and doesn’t deploy any business logic. It’s called a Passive View, which means there’s no initiative. A Presenter is very thick and that’s where all the logic is deployed.

The reason for MVP

The MVC architecture is much better than the previous hodgehodge, but there is too much interdependency between THE View and the Model. Since the View can communicate directly with the Model, the View relies on both the Controller and the Model. Controllers also depend on views and models. The coupling was still too high, so further optimization was performed. Let M and V completely disconnected, only through P to communicate.

MVVM

The MVVM mode changes the Presenter name to ViewModel, essentially identical to the MVP mode.

The only difference is that it uses data-binding, so changes to the View are automatically reflected in the ViewModel and vice versa.

For example, when the user logs in, the ViewModel looks something like this:

public class UserViewModel(a){
    String username;
    String password;
}
Copy the code

When the user clicks the “Log in” button on the interface, all you need to do is change the UserViewModel. The View is automatically updated based on changes in the ViewModel, without having to set it manually.

MVVM causes

After using it for a while, MVP realized that having a View call a Presenter method to set up the interface still required a lot of annoying code.

So the question is: Can you tell the View a data structure, and then the View automatically changes according to that data structure?

So there’s this thing called the ViewModel, which binds to the View layer. If you change the ViewModel, the View changes immediately.

conclusion

Again, all the above are the design ideas of MVC, MVP and MVVP. Specific to different language programs are different. There is no accurate definition, and the specific way to write should be defined according to the developer’s own ideas. The goal is to make the different features of the code independent, readable, and easy to expand and reuse.

Anything that doesn’t combine the project with the actual problem and talks about the architecture is rogue.

In the Spring MVC

Spring MVC takes a more complex approach to the MVC architecture pattern by adding a DispatchServlet for dispatching requests and managing views: