UI architecture-Read Martin flower related articles Summary

recently saw some of the master Martin Flower on the UI architecture of the article, in order to strengthen the understanding is summarized as follows.


from the point of view of design, the author expounds the model of the representative and influence of the UI architecture. Of course, this familiar pattern of MVC is mentioned. and from the source and evolution of MVC, we clarified the understanding of MVC. In addition to MVC, the master summarizes other patterns of the UI architecture. This article briefly summarizes the master's comments on the various models.


1. Forms and Controls
This pattern occurs at a time when the Client-server application is prevalent and later than the advent of MVC. Students have contact with VB, VC, Delphi and PowerBuilder, to deal with this is not unfamiliar.


control is what we say about controls (be careful not to confuse controllers). A control is a reusable unit that is not related to specific business logic and specific data.


A Form is a unit that is associated with a particular application logic and that is associated with many controls that can accomplish a single function.
we should be careful to differentiate between the form and the custom control. Because a custom control can be composed of multiple controls. But a form is associated with a particular business logic.
To define a form, you can start with the two functions of the form.
the first function of form is that the form is responsible for the management of the layout.
The second responsibility is that the Form is responsible for the processing of the business logic, although the control can assume some logic, but there must be some logical behavior can not be implemented by the control, there may be reuse considerations. The form needs to reconcile the behavior of individual controls in order to complete the business logic.


at the data level, this pattern depends on the data being three layers. The data that is eventually shared is stored in the database and the paper is defined as the record state. The paper defines the memory copy of the session state as the record State, so the session is supposed to be a specific session of the application and database based on this copy. Finally, the user sees the screen state.

The implementation of the mature forms and Controls mode generally gives the data Binding, the Event framework, and the Observer mode to synchronize the three states. Data synchronization is performed in a coordinated form.

Key points of this pattern:

-Write a form that is related to the application logic, and form is composed of controls;

-the form is responsible for the layout of the controls on it;

-the form listens for events triggered by the controls on it, and responds accordingly to the event;

-Simple data changes are synchronized through the binding mechanism;

-complex logic is handled in the form's listening method.

2. MVC

The concept of MVC originated in Smalltalk first. is one of the most students of the model. But the first classic MVC concept has a generation gap with today's rich clients. So it also leads to some different understandings and misuse of the concept.

The root of the pursuit of the vein, from the Smalltalk MVC.

The key here is the separated Presentation. The key to separated Presentation is to divide (domain object) domain objects and display objects (Presentation Objects, not to be confused with the Presentation model mentioned below). Domain Object is a model of the real world, the business domain. Presentation object is the data element that the GUI embodies. According to the definition of separated Presentation, domain objects are completely independent of presentation (Presentation), and can support multiple displays simultaneously with the same data on a standalone basis.

Note: We see that the definition of the data has a completely different term than the form and control. The Form and control are the record state, the Session state and the screen state. The difference is that we look at the data in different angles. The definition of the data in Form and control mode is based on the assumption that developers are heavily developed based on database records. MVC assumes that the operand is an object.

Above, we have analyzed the concept of model through the description of the core concept separated presentation. The two concepts of view and controller remain, then look.

The controller's job is to plan how to deal with the user's actions. It should be emphasized in View/controller that an application contains a lot of view-controller pairs. In the concept of Smalltalk MVC view-controller The composition of a component (component). The view is part of the display with the controller.

On Smalltalk MVC, data updates are updated through the controller to model. On the other hand, view has been updated by Observer model. Note that this is very different from form and control. Flow and control use the flow synchronization (screen code to directly and intuitively update the model to notify other controls that share it directly.) But this also leads to the coupling between the screen code. For some simple interface, for example, the Root-child style modal box, we close the modal frame directly to his root window, which is straightforward. ) in a way that synchronizes data. MVC synchronizes with observer synchronization, which corresponds to multiple screens at the same time, but the code is relatively more difficult to understand.

After discussing the data synchronization problem, there is a few awkward questions about MVC. To illustrate this, we introduce from an example, if our model has two values, set the color of a control based on the range of the difference between the two values. Calculating the difference and further mapping the difference to an attribute with a domain meaning is not difficult to understand because the model is responsible for the function. But from the model's properties to the display of the color, where should the relevant logic be placed? In the early Smalltalk, the solution to this problem was to break the purity of the domain model and participating this part of the logic into the domain model. This is an elegant approach, but we can do it occasionally:). Another relatively good practice is to encapsulate our own controls, which contain a table of values and colors, which are encapsulated into custom controls. The premise of this approach is that we need to be able to easily subclass the controls to be encapsulated. Finally, there is a way we can add a new model object. This object is intended to be displayed, where the part of the domain object is implemented by proxy (delegate). We call this Model a demonstration model (Presentation models).

Let's take a look at the important thing about MVC:

-Sparated presenation, Show (View and Controller) to strictly differentiate the model.

-Split GUI widgets into view and controller, together they form widgets. The controller is responsible for (individually, directly) reacting to the user's request and clicking on it. View is responsible for displaying the status. The view interacts with the controller through model.

-use observer synchronization to synchronize the view with the model. Supports a single piece of data for multiple view.

3. MVP (Model-view-presenter)

This pattern first appeared in IBM. Common in the last century 90 's an object-oriented operating system taligent.

MVP attempts to fuse the advantages of the first two models. The simple and intuitive Form and control. MVC's support agrees with multiple view on the data.

Here we illustrate the MVP by comparison.

Compared to the form and control, the MVP view is more like control. The view directly receives the user's stimulation and then hands over to presenter.

It's more like MVC. MVP's show is not divided into View/controller two parts, the MVP view is the display part. Presenter can be a supervising controller, but unlike the MVC controller, presenter does not directly respond to user stimuli. User stimulation is the presenter of the view. When the observer synchronization is not suitable, presenter can directly manipulate the display components.

The MVP's presenter is very similar to the MVC controller. Presenter is a loosely-structured MVC Controller. So in many framework implementations, although the implementation of the MVP style, but presenter was called Controller.

Summary of key points:

-The view widget directly accepts user stimuli and then hands over to presenter.

-Presenter is again responsible for coordinating model changes.

-this mode is fairly loose on the issue of handling view updates. Various implementations are available, from using observer synchronization to updating directly by presenter.

4.Humble View

The starting point for Humble view is testing. Especially agile development, we are popular for writing self-Test code (self-testing). The UI test has been awkward in this regard because the UI code is directly coupled to the presentation of the underlying platform. In this case, many studies are trying to minimize the behavior of objects that are difficult to test, which is humble object.

The presentation model and the supervising controller we mentioned in the previous sections have contributed in this direction. We can test the presentation model with the supervising Controller, and the rest of the logic in the humble object is hard to reach. In the case of presentation model, all logical decisions are the responsibility of the presentation model. All user events and display logic are routed to the presentation Model. The widget is only responsible for mapping attributes to the presentation model. This part of the mapping is difficult to self-testing. This non-self-testing mapping in the supervising controller can be controlled in a smaller scope because supervising controller will not need to map to manipulate widgets to cope with complex situations.

There's also a model for testing, and here's the passive View (MVC and MVP variants). It has made the best effort on humble object. Passive view not only uses a controller to react to user events, it also uses it to update the view (the view is no longer dependent on model compared to MVC). This reduces the logical behavior of the UI component to a minimum (relative to the presentation model and supervising Controller, since both require view to be responsible for updating).

This article is from the "Torrent Blog" blog, make sure to keep this source http://simonwzing.blog.51cto.com/3896700/1632202

UI architecture-Read Martin flower related articles Summary