On GUI architecture: Several Issues and patterns of GUI applications

　

Most of the applications we develop require a graphical user interface (GUI ). there are already many patterns in the architectural design of GUI applications. For example, Martin Fowler's Blog contains "Gui ubuntures", which describes form & control, MVC, MVP, passive view, presentation Model, supervising controller, event aggregator, observer synchronization, and other modes. mode helps us build an elegant architecture, but the premise is to figure out the application scenarios of the mode. these models are not created out of thin air. They are designed to solve specific problems. differences in implementation usually reflect the differences between constraints and problems. figuring out the design problems faced by GUI applications helps us to select the correct design solutions. below we will look at some common design problems of GUI applications.

The first problem isThe frequency of interface changes and business changes is different.Usually, the interface changes more frequently, and we hope that the changes on one side will not affect the logic of the other side. A natural solution to this problem is to separate the interface display logic from the background business logic. both MVC and MVP involve this. Their common feature is to separate view from other parts of the application. this is a key separation. Since then, applications have been divided into two parts. Aside from each other, they can change independently. the biggest benefit is that these two problems can also be solved separately. other parts of the application have their own problems and solutions, which are not covered in our discussion. we will focus on the view and related display logic issues later.

Of course, this separation does not have no cost. An immediate problem isView updateMVC and MVP split the view to create this problem, and they also provide a means to solve this problem.

• The MVP presenter can obtain the latest model after completing the business logic. It can manipulate the view, set various attributes of the view based on the latest model, and refresh the view.

• In MVC, the Controller updates the model after completing the business logic operation. When the model changes, an event can be triggered. View subscribes to the model update event to update itself.

• MVC has various variants. One is that the controller directly pushes the model to the view, and the view itself fetches the data of interest from the model to refresh itself.

View update processing is the main difference between MVC and MVP in implementation: MVP views do not need to know model, and presenter directly operates view. view in MVC knows the model and updates its status based on the model.

(Picture from: http://msdn.microsoft.com/en-us/library/ff647859.aspx)

　

Another common problem related to view isTestability. Even if the other split parts can be tested independently, the remaining views still hold part of the display logic. the display logic is also logic and also needs to be tested. It is relatively difficult to directly test the GUI. existing testing tools for direct GUI testing all face the following problems:

• The test takes a long time because the real application needs to be started.

• Testing is fragile, whether it is reliability or maintainability. Because the interface elements change frequently, there are often slight differences between the interface and the user's real operations through programming, especially the timing problems.

One idea is to separate the display logic from the view, so that the view degrades to the container of a simple GUI control. MVP made initial efforts, and the other two models emphasize this more: Presentation Model and passive view.

• For testability, passive view removes all display logics from the view, and the view no longer depends on any model, only the Controller or presenter is used to set and display the required data and refresh the interface.

• Presentation Model encapsulates the ing between the data owned by the domain model and the data displayed in the view. view no longer needs to deal with the domain model to convert the business data to display the required data. view only needs to retrieve data from the presentation model, and the ing logic is in the presentation model. the data required by the view and the presentation model are simple one-to-one mappings.

　

We have discussed a relatively simple gui. For example, we assume that the view corresponds to the model one by one, or even that the application has only one view. however, we still have multiple views. multiple Views bring about the following problems:

• How to maintain consistency between multiple views when the model changes

• Controllability of interaction between multiple views

• Cyclic event triggering

The flow synchronization and observer synchronization described in the Martin Fowler blog provide two ways to refresh multiple views when the model changes.

• The timing of flow synchronization's explicit definitions after model changes explicitly updates all affected views. its advantages are explicit, intuitive, and controllable. Its disadvantage is that multiple views are dependent on each other and not easy to expand. Therefore, it is suitable for scenarios with few views.

• Observer synchronization enables multiple views to subscribe to model update events. this is an application of the observer mode in synchronization and features the loose coupling of the observer. the disadvantage is not surprising. It implicitly changes the impact of user interaction, and is not easy to understand the overall behavior of the application and debugging during development.

Traditionally, mediator is also used to solve the controllability of interaction and decouple views. when we apply flow synchronization, if we extract the interaction between views to an intermediary object, each view does not know other views, but only knows the intermediary object, when an event occurs, the intermediary object updates the model and other views. Then, we can obtain clear interaction and loose coupling. let's take a look at the mediator description in <design mode>:

Intent:

• An intermediary object is used to encapsulate a series of object interactions. The intermediary removes the need for explicit mutual reference between objects, thus loose coupling and independent interaction between objects.

Applicability:

• A group of objects communicate in a well-defined but complex manner. The resulting dependency structure is confusing and hard to understand
• A group of Objects Reference many other objects and communicate directly with these objects, making it difficult to reuse the object.

Effect

• It decouples colleags. It facilitates the loose coupling between different colleags. You can independently change and reuse various colleags and mediator classes.
• Simplified object protocols. Use one-to-many interaction between mediator and colleags to replace multiple-to-many interaction.
• How does one abstract the object collaboration? Using a mediation as an independent concept and encapsulating it in an object helps to understand how objects interact in a system.
• Centralized Control. The intermediary mode changes the complexity of interaction to the complexity of the intermediary.

　

Another problem with multiple views is the cyclical triggering of events. the scenario is as follows: event a occurs-> event a processing function-> event B is triggered during processing-> Event B processing function-> event a is triggered again during processing->... in a simple example, for example, there are two text boxes on the interface. Make sure that their sum is always 100. for example, when text box A is input 30, text box B is displayed 70. when entering 40 in Text Box B, text box A will display 60. when processing the first input event, we need to set the value of the second text box. This setting will trigger event processing in the second text box, it also needs to set the value of the first text box... this loop.

There are several common processing methods for the same purpose: to minimize unnecessary event sending

• An event is triggered only when the status changes. If the status does not change, no event is triggered. textbox Control in the preceding example. if you call settext with the same parameters consecutively, except for the first call, textchanged events may be triggered, and subsequent operations will not be triggered because the text has not actually changed. triggering Events in our domain model can follow the same pattern

• Avoid re-import. when the event processing function starts event processing, it sets itself to a different state, for example, "processing". When the event processing ends, it is set back to the normal state. when a new event is triggered during event processing and the event processing function is called, you can check whether you are in the "processing" status. If yes, ignore it.

• Determine whether to handle the event based on the event source. this requires additional information in the event context, such as the event sender. microsoft's cab framework allows you to specify the scope of an event, so that the processing function can only process events within the scope of your interest.

• Strictly follow the cqrs principle. The function for updating the model and the function for refreshing the view should be two functions, namely the response to the user input event and the response to the model change event. in this way, refreshing the view will not introduce new events, reducing the chance of loops.

• Using fine-grained events. coarse granularity can lead to unnecessary responses and increase the possibility of loops.

When talking about the granularity of events, the granularity will cause another problem: it is too cumbersome to register event processing functions, and it is difficult to see the interaction. Event aggregator can solve this problem.

　

Mode

Finally, let's look at the respective highlights of several existing models.

	MVC	MVP	Presentation Model	Passive View	Flow Synchronization	Observer Synchronization	Mediator
Separation of display logic and business logic	Yes	Yes	Yes
View update		Yes	Yes	Yes
Separation of views and data (testability)	Yes	Yes		Yes
Consistency between multiple views					Yes	Yes
CONTROLLABILITY OF INTERACTION							Yes

Where:

• MVPs emphasize the separation of display logic and view more than MVC.

• MVP, presentation model, and passive view both emphasize the separation of view and display logic to different degrees: MVP introduces this separation, and the passive view separation is the most thorough and measurable. The presentation model is between the two.

• The presentation model emphasizes creating a separate model for the display logic, rather than relying on the domain model.

For more comprehensive comparison, see lauma's "Gui ubuntures" and the link in it.