The design of MVC architecture from the perspective of MVC framework

Transferred from: http://blog.csdn.net/bluishglc/article/details/6690693

the design of MVC architecture from the perspective of MVC framework

Although MVC is no longer a fresh topic, we will find some new highlights of MVC in architecture design from the design of some excellent MVC frameworks in recent years. This article will explain some of the shortcomings of the traditional MVC architecture, understand how some excellent MVC framework is to solve these problems, and reveal the design ideas and design concepts reflected in them.

MVC Review

As a classic to no longer the classic architecture model, MVC's success has its inevitable truth, this reason different people will have different interpretations, the author most agree with a view is: by the responsibility, the nature of the composition of the close together, not close to the isolation, MVC decomposition system into a model, view, controller three parts, Each part is relatively independent, the responsibility is single, in the realization process can focus on its own core logic. MVC is a kind of rational carding and slicing of system complexity, its thought essence is "separation of concerns". As for the division of responsibilities and the relationship between the three-dimensional MVC, we will not repeat this, and give a very detailed explanation.

Figure 1:MVC functions and relationships of components [i]

Decoupling of view and controller: mediator+ Two event delegation

When I developed swing-based GUI applications in the early years, I realized the tight coupling between view and controller in the practice of architecture MVC. In many event-driven GUI frameworks, such as swing, any user action on the view triggers an event, which is then handled in the listener response method. If you allow view to register as the listener of the event, you must include a reference to the controller in the view, which is not what MVC wants to see because the view and controller form a tightly coupled relationship. If the controller is registered as a listener, the event response will be assumed by the controller, which in turn will cause the controller to handle the presentation logic that it should not be involved in. The reason why view and controller is difficult to decouple is that most user requests contain a certain component of the presentation logic and a certain component of the business logic, two kinds of logic in a request, in the process of processing, view and controller can not be a reasonable division of labor. The key to solving this problem is to establish a mechanism between the view and controller that can effectively separate the presentation logic from the business logic, and in this regard, the design of the puremvc[ii] is very worthy of reference by introducing mediator+ Two event delegation mechanism solves the problem of tight coupling between view and controller very well.

Mediator is a design pattern that seems to have a common application scenario in a modular graphical interface framework, even in gang of Four's "design mode", which uses an example of a graphical interface program to explain mediator. Mediator is designed to accomplish the interaction of a set of objects through a media object, avoiding cross-referencing between objects and creating complex dependencies. Mediator when applied to graphical interface programs, it is often used as an interactive medium for a set of closely related graphical components to complete coordination between components (such as selecting a button and other components will not be available). In PureMVC, mediator is widely used, its positioning has also undergone subtle changes, it is no longer just the media between the graphics components, but also become the graphics component and command between the media, which makes it no longer optional, but become the necessary facilities in the architecture. In the traditional MVC architecture, mediator is the medium between the view and the controller (and, of course, the media between the view), and all user requests from view are mediator and passed to the controller. It has eased the close coupling problem between view and controller to some extent.

When view, mediator, and controller are defined and clear responsibilities are divided, the remaining question is how to concatenate them to complete a user request, in which event mechanisms play a vital role. The event mechanism allows the current object to focus on transactions within its area of responsibility without having to worry about who is handling it and how to handle it, the current object only needs to broadcast an event, there will be other objects interested in this event to take over the next work, there is no direct dependency between the current object and the object, It is not even possible to perceive each other's existence, which is an important reason why the event mechanism is generally considered a loose coupling mechanism. Speaking of a digression here, in the field-driven design, the well-known domain event pattern is also created by the Domain-driven of the event mechanism, which is intended to ensure the purity of the domain model, Avoid the domain model's direct reliance on repository and service. Going back to PureMVC, let's look at how the event mechanism concatenates view, mediator, and controller in the process of handling user requests. In PureMVC, when a user requests a release, the graphical component implements its own presentation logic in its own event response method, then collects the data, places the data into a new event, and broadcasts it out, which is the first event delegation. This event is monitored by a mediator, and if processing the request requires assistance from other graphical components, mediator coordinates the presentation logic that should be assumed by them, and then mediator sends an event again ( This event is called notification in PureMVC, and this event causes a command execution to complete the calculation of the business logic, which is the second event delegation. In two event delegates, the first event delegation made it easy for the graphics component to "Get Away" after "handling the presentation logic within its scope of responsibility", and to avoid being dragged down by "reconciling the rest of the artwork with the rest of the presentation logic" and "selecting and delegating business objects to handle business logic." While "coordinating other graphical components to handle the remaining presentation logic" is clearly mediator's responsibility, the first broadcast event was delegated to mediator. Mediator does not interfere with the "Select and delegate business objects to handle business logic" task after completing the coordination of the graphical components, which is not its responsibility, so the second event delegation occurs, a new incident is broadcast out by mediator, and then a command responds to it, The final work is done by command-"Select and delegate business objects to handle business logic."

Figure 2:mediator+ Two-time event delegation mechanism

Summing up, PureMVC is by introducing mediator between the view and controller, making the view and controller become indirect dependencies, and the user requests from view to mediator, From the mediator to the controller are delegated by the event, mediator+ two times the combination of 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 regression of natural grain size

At present, many platforms mainstream MVC framework in the design of the introduction of the command mode, the introduction of command mode changes the structure of the traditional MVC framework, the most impacted is the controller. In the traditional MVC architecture, a controller may have multiple methods, each of which often corresponds to a user action, so a controller often corresponds to multiple user actions, and in the command-based MVC architecture, A command often corresponds to only one user action. The process of delegating a user action to a method of a controller in a traditional MVC architecture becomes the process of binding useraction to command one by one in the command-based MVC architecture. If the traditional controller is managed in a "centralized" mapping between the user action and the model, then command-based management is a "point-to-point" direct-link mapping between the user action and the model.

Figure 3: Evolution from controller-based to command-based architecture

There is a reason for the mainstream MVC framework to shift to command, except for the advantage of command itself, a very important reason is that the controller's granularity is difficult to grip due to the lack of a reasonable organizational basis. Controller is different from view and Model,view and model have their own natural granularity organization basis, view of the organization granularity directly inherit user interface design, model organization granularity is based on some kind of analysis design thought (such as ooa/d) domain modeling results, The controller needs to coordinate both the view and model, but the organization and granularity of the view and model are not equal, which makes the controller face a problem of "How many domain objects to communicate and coordinate in the range of views", because it can't find a reasonable organization basis, Designers often feel overwhelmed when designing controllers. In contrast, command has no controller confusion, because command has a natural organizational basis, which is the user action. Designing a command for a user action, and then mapping the two together, is a very natural and simple thing to do. However, it does not mean that the granularity of all command is the same, because different user actions represent a different amount of traffic, so it also determines that the command is "big" and "small". Following good design principles, it is worth recommending that some of the "big" command be decomposed, from which some reusable parts are encapsulated into smaller "command". Many MVC frameworks define related interfaces and abstract classes to support command assembly based on combinatorial patterns.

Controller responsibilities, whether based on controllers or based on the "coordination of view and model interactions" defined in the COMMAND,MVC architecture, will not change, requiring the corresponding components and mechanisms to carry out and implement them. In a command-based architecture, command assumes part of the responsibility of the controller in the past, and in a sense command is a fine-grained controller, but the command is "passive" in character. On the one hand, it has a much weaker control over the view and model than the controller, for example, in general, the command does not manipulate the view directly. On the other hand, it does not know what kind of user action it is mapping with, and does not know under what circumstances it will be triggered to execute. Supporting command operation requires additional registration, binding, and triggering mechanisms, and these mechanisms, together with the command, implement the controller's responsibilities. Because most command-based MVC frameworks now implement and encapsulate these important mechanisms, in a sense these frameworks themselves play the role of controller.

Summary

This paper mainly analyzes the two drawbacks in the traditional MVC architecture in the past: the close coupling between view and controller and the difficulty of controlling controller granularity, and introduces how some MVC frameworks deal with these problems. The excellent design ideas embodied in these designs are well worth learning.

[i] picture source: http://java.sun.com/blueprints/patterns/MVC-detailed.html

[II] PUREMVC is an MVC framework that was originally implemented with ActionScript 3 and now has a implementation version on multiple language platforms. Official site: http://puremvc.org/

More Great blog Posts:

Domain-driven design (domain driven) Reference Architecture

on the grain size of vertical splitting vertical sharding

Introduction to Enterprise application integration and open source ESB products ServiceMix and mule

on the collection class (data access Based Collection) and domain event mode based on Access

Rethinking on the design of system anomaly

The design of MVC architecture from the perspective of MVC framework