MVC, MVP, and model2[on the previous article]

For most end-user-oriented applications, they all need to have a visual UI to interact with the user, which we call the UI view. In the early days, we tended to combine all the logic associated with views, including the rendering of data, the capture and response of user actions, and the operation of data stores such as databases. We refer to this design pattern as an autonomous view (av,autonomous views).

One, autonomous view

When it comes to autonomous views, many people may feel the pattern, but I think a lot of people (especially. NET developers) may often use this pattern to design our applications. Windows forms and ASP.net Web forms are both GUI and web development frameworks, but they all take the form of event-driven development. All UI-related logic can be defined in the code behind for the view (Windows form or Web Form) and eventually to the corresponding event in the view itself or the view element (control).

A typical human-computer interaction application has three main concerns, namely, the rendering of data on a visual interface, the UI processing logic (the logic used to handle user interactive operations), and the business logic. For autonomous view patterns, the fact that these three are mixed together is bound to pose some of the following problems:

First, the business logic is UI-independent and should be reused to the maximum extent possible. Because the business logic is defined in the autonomous view, the equivalent is completely bound to the view itself. If we can abstract the behavior of the UI, the processing logic based on the abstract UI can also be shared, and the UI processing logic defined in the autonomous view completely loses the possibility of reuse.

Second, the business logic has the strongest stability, the UI processing logic takes the next place, and the visual interface renders the worst, for example, we often adjust the HTML for better rendering. It is the embodiment of "short board theory" in software design that the elements with different stability are integrated and the element with the worst stability determines the stability of the whole.

Again, any component that involves the UI is not easily tested. The UI is presented to people, and it's used to interact with people, and it's not easy to use a machine to simulate a living person to automate a component, and the autonomic view seriously impairs the testability of the component.

To address these problems caused by autonomous views, we need to adopt a policy of separation of concerns (SoC, seperation of concerns) to separate visual interface rendering, UI processing logic, and business logic, and to minimize the impact between them using a reasonable interaction approach. Because of the "divide and conquer" of the three, nature also makes the UI logic and business logic easy to test components, so that test-driven design and development become possible. The pattern used here for separation of concerns is MVC.

Second, the MVC pattern

The founder of MVC is Trygve M. Reenskau, a computer expert in Norway and an honorary professor at the University of Oslo. MVC was his visit to the Xerox Parc,xerox Palo Alto Research Center in 1979 to propose a software architecture model primarily for GUI applications. MVC was originally used to smalltalk,trygve the initial description of MVC in the Applications programming in SMALLTALK-80 (TM):

In this paper, you can use Model-view-controller (MVC) as an interested reader through the address http://st-www.cs.illinois.edu/users/smarch/st-docs/ mvc.html read this essay. MVC embodies the focus of separation of the basic design policy, it will constitute a human-computer interaction application involved in the functions of model, controller and view three parts, the three have their own basic functions or functions are as follows:

Model: Is the application of the State and business functions of encapsulation, can be seen as the same time contains data and behavior of the domain models (domain model). Model accepts Controller's request to perform corresponding business functions and notifies view when state changes.

View: Enables the rendering of a visual interface to capture end-user interactions (such as mouse and keyboard operations).

Controller:view captures the user interaction and then sends it directly to the Controller, which completes the appropriate UI logic. If calls involving business functions are required, controller will call model directly. After UI processing is complete, controller controls the original view or creates a new view to respond to user interaction actions as needed.

The following figure shows the interaction between model, view, and controller in the MVC pattern. For the traditional MVC pattern, many people think that controller is only the intermediary between view and model, in fact, there is a direct link between view and model. View can call the model directly to query its state information. When the model state changes, it can also directly notify view. For example, in an application that provides a real-time price for stocks, the model that maintains the stock price information can directly notify the relevant view to change its display information when the stock price changes.

From the point of view of the message Exchange Mode, the model for view state notification and view for controller user interaction notifications are one-way, we recommend that the event mechanism to implement these two types of notifications. From the design pattern point of view is to use the Observer (OBSERVER) mode through registration/subscription to implement them, that is, view as model observer by registering the corresponding events to detect changes in state, Controller as the observer of the view handles the user's interactions by registering the appropriate events.

MVC in multi-layered architecture

I've seen a lot of people comparing MVC with the so-called "three-tier architecture," and there's nothing comparable between them, and MVC doesn't correspond to three levels of UI, business logic, and data access respectively. But neither can be said at all, and we are going to talk about it now.

Trygve M. Reenskau when the MVC was proposed, it was actually used as the architectural model for building the entire GUI application, while model maintained the state of the application and implemented all the business logic, which was more of a domain model. For multi-tier architectures, such as the three-tier architecture we often refer to, MVC is considered a design pattern for the UI rendering layer (presentation Layer), while model is more of a gateway to the business layer. If a service-oriented design is used to define a business function as a corresponding service and exposed through an interface (contract), the model can even be represented as a proxy for service invocation.