Introduction to MVC

As long as they are connected to MVC, they are bound to be inseparable from Layer 3. Many people will be entangled in the differences between them. It is no wonder that there are similarities between them: they are divided into three parts, without careful consideration, it seems that everything is the same, and the online saying is also a hundred schools of contention. This article only introduces the understanding of MVC. Since learning is a step-by-step process, we have not yet fully understood it, and there is no need to distinguish between them, I do not dare to comment on Layer 3 or MVC. It is only a process of recording this learning cognition. I hope to communicate with you. Over time, my understanding is constantly refreshing.

======== Start Question ========

Model-View-controller (MVC) was proposed by Trygve reenskaug in 1974. It was a software design model invented by Xerox PARC in 1980s for the program language smalltalk. The purpose of the MVC pattern is to implement a dynamic program design, simplify subsequent modifications and extensions of the program, and make reuse of a part of the program possible. In addition, this mode simplifies the complexity to make the program structure more intuitive.
The design concept of MVC is that the input, processing, and output processes of an application are separated by model, view, and controller, such an application is divided into three layers: model layer, view layer, and control layer.

Features of each layer:

Model: mainly responsible for business logic and database interaction. It is used to encapsulate data related to the application's business logic and to process the data. The "model" has the right to directly access data, such as accessing databases.
View: displays and submits data. The view layer can display data purposefully. Generally, there is no program logic in the view.
Controller: Mainly used to capture requests and control request forwarding. It serves as an organizational unit at different levels and is used to control application processes. It processes events and responds. "Events" include user behaviors and changes in data models.

Relationship between the three:

Event causes the Controller to change the model or view, or change both. As long as the controller changes the data or attributes of models, all dependent views are automatically updated. Similarly, as long as the controller changes the view, the view will retrieve data from the potential model to refresh itself.

Two separation of MVC:
I: View and model separation: model focuses on internal invisible logic, while view focuses on external visible logic. In this way, different views can be developed for the same Moudle for presentation, and the visualization and non-visual separation can also make the modle relatively independent, the coupling is reduced, and independent tests can be conducted.
II: View and controller separation: this separation is not very important, because view and controller often have a one-to-one relationship. The controller uses one-way reference to view, so that the controller can be tested independently.

Development of MVC:
What we usually talk about most is the earliest proposed MVC model, also known as classic MVC. For detailed evolution reference (MVC Evolution History), I will not repeat it here.

Advantages of MVC:

The most important thing is that multiple views correspond to one model, which greatly improves the robustness of software and the reusability of code. An application is separated into three layers, new requirements can be met by changing specific layers, which is also easy to maintain and conducive to software engineering management.

Disadvantages:
(1) added the complexity of system structure and implementation. For a simple interface, strictly abide by MVC. Separating Models, views, and controllers will increase the structure complexity, prolong the software development cycle, and lead to too many update operations, reduce operation efficiency.
(2) The views and controllers are too closely connected. Views and controllers are isolated from each other, but they are closely related. A view does not have a controller and its applications are limited. Vice versa, which hinders independent reuse.
(3) inefficient access of views to model data. Depending on the model operation interface, the view may need to be called multiple times to obtain sufficient display data. Unnecessary frequent access to unchanged data will also damage operation performance.
(4) Currently, Advanced Interface tools or constructors do not support the MVC Architecture. It is costly to transform these tools to adapt to MVC needs and build separation components, resulting in difficulties in using MVC.

Appendix: some of the materials are from the Internet, and the shortcomings are still expected.