Classic MVC In the 1970s, Xerox PARC’s Trygve proposed the concept of MVC.
It is also used in the Smalltalk system. In order to distinguish it from other types of MVC, it is customary to call it Classic MVC.
Classic Mvc mode
Model: Packaging domain data and logic
View: Query domain data and present it to users
Conctroller: Intercept user requests and change domain data
From a dependency perspective, Model does not rely on View and Controller, while View and Controller depend on Model.
Classic MVC focuses on two separations:
Separate View from Model
Separate the Controller from the View
Separating View from Model is based on the following considerations:
Different concerns: Model focuses on intrinsic invisible logic, while View focuses on externally visible logic.
Multiple forms of expression: The same Model often requires multiple View representations, such as text and images.
Improve testability: Compared to Model, View is not easy to test.
Separating the Controller from the View is not that important.
In the era of software development, View and Controller are often one-to-one correspondence, so they are often merged into a UI. In fact, most UI frameworks at the time did not implement the separation of Controller from View. Later, with the rise of the Web, this separation (template technology) became popular.
In essence, the structure of Classic MVC is shown in the following figure. The reason is that View and Controller are actually related to each other, but this association is completely different from the MVP mentioned later, more like a by-product of the framework.
The Controller intercepts the request made by the user through the mouse or keyboard, and then changes the state of the Model. The Model notifies the View that its status has changed through Observer Synchronization.
View query Model shows data.
Classic MVC is not perfect and does not apply to complex logic.
The user adjusts the volume by dragging the scroll bar with the mouse. If the volume is greater than a certain value, the background color turns red to indicate a reminder. When using Classic MVC, how do you deal with the logic of background color reddening?
There are two options:
The Model triggers a special event, and the View completes the processing of the relevant logic. But as we said before, from the perspective of dependencies, Model should completely ignore the existence of View.
The volume threshold is judged in the View, and the processing of the relevant logic is completed after the completion. But as we said before, View is not easy to test, and logic processing should be minimized.
Application Model MVC
In the 1980s, ParcPlace was divided from Xerox Parc and was responsible for the development of Smalltalk. In order to adapt to more complex logic, an improved version of Classic MVC, also known as Application Model MVC, was introduced. Based on the original architecture, Application Model was introduced. ,As shown below:
The Application Model acts as a repeater between the Model and the View and Controller.
Then look at the previous example, since Model and View are not suitable for the background color to turn red logic, then we can try to put the relevant logic in the Application Model implementation, when the user adjusts the volume through the mouse, the Model triggers a normal event, The Application Model intercepts this event and determines if the volume is greater than the threshold. If it is, it triggers a special event, and the View completes the processing of the relevant logic.
Although Application Model MVC seems to solve the problem of complex logic, it still has a flaw:
First, with the rise of the Microsoft Windows-based graphical operating system, the operating system itself provides a native View interface to intercept requests from users via the mouse or keyboard.
As a result, the Controller is redundant.
Secondly, in Application Model MVC, View rendering can only be achieved through events. Application Model can’t directly operate View, so in some cases it is not convenient to implement business logic. Then, as mentioned above, the example of adjusting the volume, this time we add a new function, no longer drag the scroll bar to adjust the volume, but give a text box, let the user directly input the Arabic numerals through the keyboard to indicate the volume. Once the user enters illegal content (such as English characters), the background color turns yellow to indicate a warning. The problem is that if the user enters illegal content, the state of the Model should not be changed, but without changing the state of the Model, the View has no chance to receive the rendered event.
In the 1990s, IBM’s Mike Potel proposed the concept of MVP . At the same time, the Smalltalk team is developing a new generation of frameworks. When they saw MVP, they found that it was not only very similar to MVC, but also solved the problem of complex logic very well, so decided to use it, due to the complexity, They simplified the MVP, and in the end it looked more like a reversal of the original MVC, and reversed the VCs in the following order:
The View intercepts the user request and then delegates to the Presenter. The Presenter changes the state of the Model. The Model notifies the View that its state has changed through Observer Synchronization. The View query Model displays the data.
The most important thing is that Presenter and View hold each other’s references to each other. Although View intercepts the user request, it does not process it, but delegates it to the Presenter for guaranteed testability. At the same time, because Presenter can directly manipulate the View, it is not limited to the observer mode.
Following the example of adjusting the volume, when the user drags the scroll bar to adjust the volume, the View intercepts the request and delegates the request to the Presenter. If the Presenter finds that the volume is greater than the threshold, the View implements the logic directly; When the volume is input through the keyboard, View intercepts the request and delegates the request to the Presenter. If the Presenter finds that the content is illegal, it directly manipulates the View implementation logic.
Two categories of MVP: Supervising Controller and Passive View
The difference between the two is whether the Model and the View are related. In the implementation of the Supervising Controller, the View can query the Model. If the state of the Model changes, the View will be notified. In the implementation of the Passive View, the View cannot query the Model, and the Model state occurs. Changes will notify the Presenter, and the Presenter will render the View. In comparison, Passive View is more testable, but Presenter has a larger amount of code.
Earlier we discussed the evolution of MVC to MVP. With the rise of the Web, people began to apply MVC, MVP and other knowledge to the Web environment, but the Web environment has its particularity. The most important point is that HTTP is stateless. Each request is independent, so it is not possible to implement the observer mode.
Java is a Web MVC earliest practitioners to develop a Model 2 , the use of JavaBean, JSP, Servlet corresponding to the three components of the MVC, followed Structs emergence began to make public notice Web MVC, but the real popular Web MVC It’sthe Rails community of Ruby , and the general flow is shown below:
A typical Web MVC process
Controller intercepts requests from users
The Controller calls the Model to complete the read and write operations of the state.
Controller passes data to View
View renders the final result and presents it to the user
In Classic MVC, Controler can change the state of the Model. View can query the state of the Model. Therefore, for Model, the status of Controller and View is equal, but in Web MVC, Controller becomes a repeater. The job is to coordinate Model and View, so it seems that the Controller in Web MVC is equivalent to the Presenter in MVP. Then why not call Web MVP, but call it Web MVC? This is because the interception request is a Controller instead of a View.
In the era of Desktop, Microsoft realized MVP through WinForms, and brought component programming to the extreme, greatly improving the development efficiency. With the rise of the Web, Microsoft hopes to continue this programming mode, so Web MVP is implemented using WebForms, and CodeBehind is introduced. , ViewState and other design concepts. The advantages and disadvantages of WebForms are outstanding, and the space is limited
Note: Microsoft introduced ASP.NET MVC to Web MVC, it seems that it is hard to grab both hands.
Microsoft Web MVP vs Web MVC. Note that the interception request is a Controller or a View!