Introduction to the MVC architecture

This article compiles the relevant documents from the Java EE.
The MVC (model-view-controller) application architecture is used to analyze the characteristics of distributed applications. This abstract structure can help to split the application into logical parts, making programming easier.

The MVC architecture provides a way to split various objects by function, which are used to maintain and represent data, in order to minimize the degree of coupling between objects. The MVC structure was originally designed to apply traditional input, processing (processing), and output (outputs) tasks to a graphical user interaction model. However, it is also appropriate to apply these concepts to the Web-based enterprise-level multi-tier application area.

In the MVC structure, the model represents the data of the application and the business rules that govern access to and modification of the data. The model is often used as a software approximation to a process in the real world, and when a model is defined, simple modeling techniques can be used.

When the model changes, it notifies the view, and provides the ability to query the state of the model in relation to the view. It also provides the controller with the ability to access application functionality encapsulated within the model.

A view is used to organize the content of the model. It obtains data from the model and specifies how the data behaves. When the model changes, it is responsible for maintaining the consistency of the data performance. The controller is also informed of the user requirements.

The controller defines the behavior of the application, and it is responsible for interpreting the user requirements from the view and mapping the requirements to the appropriate behavior, which is implemented by the model. In a standalone GUI client, user requirements may be a few mouse clicks or menu selection actions. In a Web application, they may be represented by a GET or post HTTP request from the client. The behavior that the model implements involves processing the business and modifying the state of the model. Depending on the user requirements and the results of the model behavior, the controller chooses a view as a response to the user request. Typically a set of related feature sets corresponds to a controller. Describes the three-part relationships of models, viewports, and controllers in an MVC application:

The solid line in the figure represents a high-coupling dependency, and the dashed lines represent a low-coupling message relationship. The business module is independent of the user interface, thus isolating the impact of user interface changes on the business process. The user interface is responsible for collecting the user's input, displaying the data that the user needs, and the controller is responsible for invoking the user's request to the actual business program and returning the results of the business process to the user interface; At the same time the business module may actively send messages to the user interface, the notification interface display data.

In a specific environment, these factors may vary. For example, in web development, the user interface is run on a browser because of the nature of the Web application, and the interface controls and business modules run on the browser, so this typical MVC pattern is typically used in Web applications. And in the Web application, there is no server actively "push" the data to the client, so the dashed line from model to view does not exist. In a Windows Forms program, the controller and interface are often merged, such as the Document-view pattern used in the MFC framework, where document corresponds to model in MVC, is responsible for saving business data, processing business logic, View is equivalent to View+controller in MVC, which is responsible for the display of user interface, the collection of user input and the jump control of the screen.

Introduction to the MVC architecture