MVC Framework

MVC stands for Model View Controller, which is an abbreviation for model-view-controller. It is a widely applied software design paradigm. Its core idea is to organize the code by separating the business logic, data, and interface display, and centralize the business logic in one component. In this way, when improving and customizing the interface and user interaction, there is no need to rewrite the business logic. MVC has uniquely developed to map the traditional input, processing, and output functions into a logical graphical user interface structure.

MVC Programming Pattern

MVC is a pattern for creating web applications using the MVC (Model View Controller model-view-controller) design. The specific introduction is as follows:

+-------------------+
|       Model       |
|  The core of the application, such as  |
|  the database, etc., is responsible for  |
|  handling data logic and  |
|  accessing and storing data          |
+-------------------+
          |
          | Provide data
          ▼
+-------------------+
|       View        |
|  Display effects, such as  |
|  HTML pages, etc.,  |
|  Create display content based on model data  |
+-------------------+
          |
          | User interaction
          ▲
+-------------------+
|     Controller    |
|  Handle input, including  |
|  business logic, and is responsible for  |
|  reading data from the view,  |
|  controlling user input,  |
|  and sending data to the model  |
+-------------------+

Model: Represents the core of the application, such as the database, etc. It is mainly responsible for handling the data logic of the application. Usually, model objects undertake the task of accessing and storing data in the database.
View: Used for display effects, such as common HTML pages, etc. The view is generally created based on model data.
Controller: Handles user interaction, usually responsible for reading data from the view, controlling user input, and sending data to the model.

The MVC pattern also provides complete control over HTML, CSS, and JavaScript.

Advantages

Low Coupling: The view layer and the business layer are separated, which means that when changing the view layer code, there is no need to recompile the model and controller code. Similarly, when the business process or business rules of the application change, only the model layer of the MVC needs to be modified. Since the model is separated from the controller and the view, it is easy to adjust the data layer and business rules of the application. For example, if you want to migrate the database from MySQL to Oracle, or change from an RDBMS data source to LDAP, you only need to modify the model part. Once the model is correctly implemented, regardless of whether the data source is a database or an LDAP server, the view can correctly display the corresponding data. Because the three components of an MVC application are independent of each other, changing one of them will not affect the other two. Therefore, a well-loosely coupled system can be built based on this design idea.
High Reusability: With the development of technology, there is a need to access the application in multiple ways. The MVC pattern allows various different styles of views to access the same server-side code, because multiple views can share one model, including any WEB (HTTP) browser or wireless browser (wap). For example, users can order a certain product through a computer or a mobile phone. Although the ordering methods are different, the business logic for processing the product ordering is the same. Since the data returned by the model is not formatted, the same component can be used by different interfaces. For example, a lot of data may be represented in HTML, and it may also be represented in WAP. The operations required to achieve these different representations are just to change the implementation method of the view layer, and the control layer and the model layer do not need to be changed at all. Since the data and business rules have been separated from the presentation layer, the code can be reused to the greatest extent. The model also has the functions of state management and data persistence processing. For example, the session-based shopping cart and e-commerce process can also be reused by Flash websites or wireless networked applications.
Low Lifecycle Cost: MVC reduces the technical content of developing and maintaining the user interface.
Fast Deployment: Using the MVC pattern significantly reduces the development time. It enables programmers (Java developers) to focus on business logic, and interface programmers (HTML and JSP developers) can focus on the presentation.
High Maintainability: Separating the view layer and the business logic layer also makes web applications easier to maintain and modify.
Beneficial for Software Engineering Management: Since different layers perform their respective functions, different applications in each layer have certain common characteristics, which is beneficial for managing program code through engineering and tooling. The controller also provides an advantage that it can be used to connect different models and views to complete user requirements. In this way, the controller can provide a powerful means for constructing applications. Given some reusable models and views, the controller can select the model for processing according to user requirements and then select the view to display the processing results to the user.

Disadvantages

No Clear Definition: It is not easy to fully understand MVC. Using MVC requires careful planning. Since its internal principles are relatively complex, it takes some time to think about it. At the same time, due to the strict separation of the model and the view, it also brings certain difficulties to debugging the application. Each component needs to be thoroughly tested before use.
Not Suitable for Small and Medium-Sized Applications: Spending a lot of time applying MVC to applications that are not very large is often not worth the effort.
Increases the Complexity of the System Structure and Implementation: For simple interfaces, strictly following MVC and separating the model, view, and controller will increase the complexity of the structure and may generate too many update operations, reducing the operating efficiency.
Too Tight Connection between the View and the Controller: The view and the controller are separate but closely related components. The application of the view is very limited without the existence of the controller, and vice versa. This hinders their independent reuse.
Inefficient Access to Model Data by the View: Depending on the operation interface of the model, the view may need to be called multiple times to obtain enough display data. Unnecessary frequent access to unchanged data will also damage the operation performance.
General Advanced Interface Tools or Constructors Do Not Support the Pattern: The cost of transforming these tools to adapt to MVC and establishing separate components is high, which will cause difficulties in using MVC.

MVP Pattern

Full name: Model-View-Presenter. MVP evolved from the classic MVC pattern. Their basic ideas are similar, that is, the Controller/Presenter is responsible for logical processing, the Model provides data, and the View is responsible for display.

+-------------------+
|       Model       |
|  Provide data and be responsible for  |
|  handling data-related logic  |
+-------------------+
          |
          | Provide data
          ▼
+-------------------+
|       View        |
|  Display data, the user interface part  |
+-------------------+
          |
          | User interaction
          ▲
+-------------------+
|     Presenter     |
|  Handle logic, interact between the model  |
|  and the view, and coordinate the data flow  |
+-------------------+

Advantages

Complete Separation of the Model and the View: We can modify the view without affecting the model.
More Efficient Use of the Model: Because all interactions occur in one place - inside the Presenter.
High Reusability: We can use one Presenter for multiple views without changing the logic of the Presenter. This feature is very useful because the view changes more frequently than the model.
Easy to Test: If we put the logic in the Presenter, then we can test these logics (unit tests) without the user interface.

Disadvantages

Since the rendering of the view is placed in the Presenter, the interaction between the view and the Presenter will be too frequent. It should also be understood that if the Presenter renders the view too much, it will often make its connection with a specific view too close. Once the view needs to be changed, then the Presenter also needs to be changed. For example, if the Presenter originally used to present Html now also needs to be used to present Pdf, then the view is likely to need to be changed as well.

Differences between MVP and MVC

As a new pattern, MVP has a significant difference from MVC: In MVP, the View does not directly use the Model. The communication between them is carried out through the Presenter (the Controller in MVC), and all interactions occur inside the Presenter. In MVC, the View will directly read data from the Model instead of through the Controller.

In MVC, the View can directly access the Model. As a result, the View will contain Model information and inevitably some business logic. In the MVC model, more attention is paid to the change of the Model, and there are multiple different displays of the Model at the same time, that is, the View. Therefore, in the MVC model, the Model does not depend on the View, but the View depends on the Model. Moreover, because some business logic is implemented in the View, it is more difficult to change the View, and at least those business logics cannot be reused.

Although the View in MVC can indeed "access" the Model, we do not recommend relying on the Model in the View. Instead, we require that all business logic be processed in the Controller as much as possible, and the View only interacts with the Controller.

The differences are shown in the following figure (here you can refer to the original pictures mvc.png and mvp.png you provided):

MVVM Framework

MVVM is the abbreviation of Model-View-ViewModel. It is essentially an improved version of MVC. MVVM abstracts the state and behavior of the View, allowing us to separate the view UI and business logic. Of course, the ViewModel has already done this for us. It can extract the data of the Model and at the same time help process the business logic involved in the View due to the need to display content. Microsoft's WPF brings new technical experiences, such as Silverlight, audio, video, 3D, animation..., which has led to the software UI layer being more detailed and customizable. At the same time, at the technical level, WPF also brings new features such as Binding, Dependency Property, Routed Events, Command, DataTemplate, ControlTemplate, etc. The origin of the MVVM (Model-View-ViewModel) framework is a new type of architecture framework that evolved from the application method of combining the MVP (Model-View-Presenter) pattern with WPF. It is based on the original MVP framework and incorporates the new features of WPF to deal with the increasingly complex changes in customer needs.

Components of the MVVM Pattern

+-------------------+
|       Model       |
|  Domain model (object-oriented) or data access layer  |
|  (data-centered), representing the real state content  |
+-------------------+
          |
          | Provide data
          ▼
+-------------------+
|     ViewModel     |
|  The abstraction of the view, exposing public properties and commands,  |
|  communicating between the view and the data binder  |
+-------------------+
          |
          | Two-way binding
          ▲
+-------------------+
|       View        |
|  The structure, layout, and appearance (UI) that the user sees on the screen  |
+-------------------+

Model: The model refers to the domain model (object-oriented) representing the real state content, or the data access layer (data-centered) representing the content.
View: Just like in the MVC and MVP patterns, the view is the structure, layout, and appearance (UI) that the user sees on the screen.
ViewModel: The view model is the abstraction of the view that exposes public properties and commands. MVVM does not have the controller in the MVC pattern, nor the presenter in the MVP pattern, but has a binder. In the view model, the binder communicates between the view and the data binder.
Binder: Declarative data and command binding are implicit in the MVVM pattern. In the Microsoft solution stack, the binder is a markup language called XAML. The binder frees developers from being forced to write boilerplate logic to synchronize the view model and the view. When implemented outside the Microsoft stack, the emergence of declarative data binding technology is a key factor in implementing this pattern.

Advantages of MVVM

Like the MVC pattern, the main purpose of the MVVM pattern is to separate the view (View) and the model (Model), and it has several major advantages:

Low Coupling: The view (View) can change and be modified independently of the Model. One ViewModel can be bound to different "Views". When the View changes, the Model can remain unchanged, and when the Model changes, the View can also remain unchanged.
Reusability: You can put some view logic in a ViewModel and let many views reuse this view logic.
Independent Development: Developers can focus on the development of business logic and data (ViewModel), and designers can focus on page design. Using Expression Blend, it is easy to design the interface and generate xaml code.
Testability: The interface has always been relatively difficult to test, and now tests can be written for the ViewModel.

Differences between MVVM and MVP

The mvvm pattern renames the Presener to View Model, which is basically exactly the same as the MVP pattern. The only difference is that it uses two-way binding (data-binding): changes in the View are automatically reflected in the View Model, and vice versa. In this way, developers do not need to deal with the work of receiving events and updating the View, and the framework has already done it for you.