Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the design concept of MVC framework". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the design concept of MVC framework".

MVC Review

As a classic to no longer classic architecture model, the success of MVC has its inevitable reason, and different people will have different interpretations of this truth. The author most agrees with the point of view: by summing up the components with similar responsibilities and properties, and isolating those that are not similar, MVC decomposes the system into three parts: model, view and controller, each part is relatively independent, and the responsibility is single. In the implementation process, you can focus on your own core logic. MVC is a reasonable carding and segmentation of system complexity, and its essence is "separation of concerns". As for the division of responsibilities and the relationship between the three elements of MVC, I will not repeat them here, and the following figure gives a very detailed explanation.

Figure the functions and relationships of 1:MVC components [I]

Decoupling of View and Controller: mediator+ secondary event delegation

When developing GUI applications based on swing in the early years, the author deeply realized the problem of tight coupling between view and controller in the practice of building MVC. In many event-driven GUI frameworks, such as swing, any user action on view triggers an event and then handles it in the listener's response method. If you let view register itself as the listener of the event, you must include a reference to controller in the view, which is not what MVC wants, because view and controller are tightly coupled. If controller is registered as listener, the event response will be borne by controller, which will cause controller to deal with presentation logic that should not be involved. The reason why it is difficult to decouple between view and controller is that most user requests contain a certain component of presentation logic and a certain component of business logic, and the two logic are combined in one request. When processing, it is difficult for view and controller to work together. The key to solve this problem is to establish a mechanism between view and controller that can effectively separate presentation logic from business logic. in this regard, the design of PureMVC [ii] is very worthy of reference. it solves the problem of tight coupling between view and controller by introducing mediator+ secondary event delegation mechanism.

Mediator is a design pattern, which seems to have a common application scenario in the component-based graphical interface framework. Even in the book Design patterns of the Gang of four, an example of a graphical interface program is used to explain mediator. The design purpose of mediator is to complete the interaction of a group of objects through a media object, so as to avoid the mutual reference between objects and produce complex dependencies. When mediator is used in graphical interface programs, it is often used as an interactive medium for a group of closely related graphical components to complete the coordination between components (such as clicking a button and other components will not be available). In PureMVC, mediator is widely used, and its positioning has undergone subtle changes. It is no longer just a medium between graphics components, but also a medium between graphics components and command, which makes it no longer optional, but a necessary facility in the architecture. Corresponding to the traditional MVC architecture, mediator is the medium between view and controller (of course, it is still the medium between view). All user requests from view are passed through mediator and then passed to controller, which alleviates the problem of tight coupling between view and controller to some extent.

When view, mediator, and controller are defined and clearly divided into responsibilities, the remaining question is how to concatenate them to complete a user request, in which the event mechanism plays a vital role. The event mechanism allows the current object to focus on dealing with transactions within its scope of responsibility, regardless of who handles the excess part and how it is handled. The current object only needs to broadcast an event. Other objects interested in this event will come out to take over the next step of the work. There is no direct dependence between the current object and the receiving object, and they are not even aware of each other's existence. This is an important reason why the event mechanism is generally regarded as a loose coupling mechanism. As an aside, in Domain-Driven Design, the famous Domain Event pattern is also created by the feature of event mechanism, which is intended to ensure the purity of the domain model and avoid the direct dependence of the domain model on repository and service. Going back to PureMVC, let's take a look at how the event mechanism concatenates view, mediator, and controller during the processing of user requests. In PureMVC, when a user requests, the graphics component first implements its own presentation logic in its own event response method, and then collects data, places the data into a new event, and broadcasts it. This is the first event delegation. The event will be monitored by a mediator, and if the request requires the assistance of other graphical components, the mediator will coordinate them to handle the presentation logic that should be borne by them, and then the mediator will send an event again (this time the event is called a notification in the PureMVC), and the event will cause a command to execute and complete the calculation of the business logic, which is the second event delegation. In the two event delegates, the first event delegation allows the graphics component to easily "get away" after "handling presentation logic within its scope of responsibility". Free from being dragged down by "coordinating other drawings to handle the remaining presentation logic" and "selecting and delegating business object processing business logic". It is obviously mediator's responsibility to "coordinate with other graphical components to deal with the remaining presentation logic," so the first broadcast event is delegated to mediator. After completing the coordination of the graphical components, mediator does not intervene in the task of "selecting and delegating business objects to handle business logic", which is not its responsibility, so a second event delegation occurs, a new event is broadcast by mediator, and a command responds, and command completes the final job-- "Select and delegate business objects to handle business logic".

Figure 2. Mediator + secondary event delegation mechanism

To sum up, PureMVC makes view and controller indirectly dependent by introducing mediator between view and controller, and user requests from view to mediator, and then from mediator to controller are delegated by events. The combination of mediator+ secondary event delegation can be said to be a "powerful" decoupling mechanism, which realizes the complete decoupling between view and controller.

From Controller to Command, the return of Natural granularity

At present, command pattern is introduced into the design of the mainstream MVC framework of many platforms, and the introduction of command pattern has changed the structure of the traditional MVC framework, and the one who is most affected is controller. In the traditional MVC architecture in the past, a controller may have multiple methods, and each method often corresponds to a user action, so a controller often corresponds to multiple user action, while in the command-based MVC architecture, a command often corresponds to only one user action. The process of delegating a useraction to a method of a controller in the traditional MVC architecture becomes a process of binding useraction to command one by one in the command-based MVC architecture. If the traditional management mode of controller is to establish a "centralized" mapping between user action and model, then the management method based on command is to establish a "point-to-point" direct mapping between user action and model.

Figure 3: evolution from Controller-based to Command-based architecture

There is a reason for the transformation of the mainstream MVC framework to command. In addition to the advantages of command itself, a very important reason is that due to the lack of a reasonable organizational basis, the granularity of controller is difficult to handle. Different from view, model,view and model, controller has its own natural granularity and organization basis. The organizational granularity of view directly inherits the user interface design, while the organizational granularity of model is the result of domain modeling based on some analytical and design ideas (such as OOA/D). Controller needs to coordinate view and model at the same time, but the organizational structure and granularity of view and model are not equal. As a result, controller is faced with the problem of "how many domain objects to communicate and coordinate in what view range". Because there is no reasonable organization basis, designers often feel at a loss when designing controller. By contrast, command has no controller confusion at all, because command has a natural organizational basis, which is user action. It is very natural and simple to design a command for a user action and then map the two together. However, it should be noted that this does not mean that the granularity of all command is the same, because different user action represent different volume of business, so it also determines that command is "big" and "small". Following good design principles, it is recommended to decompose some "large" command and extract some reusable parts from them and package them into some "small" command. Many MVC frameworks define related interfaces and abstract classes to support command assembly based on composition patterns.

No matter the controller responsibility of "coordinating the interaction between view and command,MVC" defined in controller or model architecture will not change, it needs corresponding components and mechanisms to carry and implement. In the command-based architecture, command takes on some of the responsibilities of controller in the past. In a sense, command is a kind of fine-grained controller, but the characteristic of command is "passive". On the one hand, its control over view and model is much weaker than that of controller. For example, in general, command does not directly manipulate view. On the other hand, it doesn't know what kind of user action it is mapped to, or under what circumstances it will be triggered to execute. Supporting the operation of command requires additional registration, binding, and triggering mechanisms that, together with command, fulfill the responsibilities of controller. Since most command-based MVC frameworks implement and encapsulate these important mechanisms, in a sense, these frameworks themselves play the role of controller.

Thank you for your reading, the above is the content of "what is the design concept of MVC framework". After the study of this article, I believe you have a deeper understanding of what the design concept of MVC framework is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.