Supervising controller-Martin's "Gui ubuntures" series (2)

ZZ from www.martinfowler.com

To be translated...

Supervising Controller

Factor the UI into a view and controller where the view handles simple mapping to the underlying model and the Controller handles input response and complex view logic.

[TBD: Not sure yet whether to use the word 'controller' or 'presenter 'here.]

Define UI frameworks provide the ability to easily map between the view and model, often using some kind of data binding. these approaches are very internal tive in allowing you to declaratively set up a relationship between elements in the view and model. usually, however, there are more complex relationships which require you to have more complex view logic. this logic can be hard to manage, and in special hard to test, while embedded in the view.

Supervising ControllerUses a controller both to handle input response but also to manipulate the view to handle more complex view logic. it leaves simple view behavior to the declarative system, intervening only when effects are needed that are beyond what can be achieved declaratively.

How it works

Supervising ControllerDecomposes presentation functionality into two parts: a controller (often called presenter) and view. the domain data that needs to be displayed is separate, and following rough MVC terminology I'll refer to it as a model, although it need not be a domain model. the basic division of responsibilities echoes the Model-View-presenter architecture in its doldolphin form, as described by bower and McGlashan.

ASupervising ControllerHas two primary responsibilities: input response and partial view/model synchronization.

For input response the controller operates in the presenter style. the user gestures are handled initially by the screen widgets, however all they do in response is to hand these events off to the presenter, which handles all further logic.

For view/model synchronization the Controller defers as much of this as reasonable to the view. the view typically uses some form of Data Binding to populate much of the information for its fields. where data binding isn't up to more complex interactions then the Controller steps in.

Figure 1: Class dimo-for the assessment example.

Figure 2: sequence dimo-showing the response for putting in a low actual value.

In the assessment window, the initial text change is handled by the text Field widget in the view. this widget is observed by the Controller, so when the text changes the widgets emits an event which results in the Controller's Actualfieldchanged Method being called. this method then handles the full response to the event. it first updates the reading model object's actual value. the window observes the reading object so the change to the reading's value triggers a refresh. it's pretty easy to map the actual and variance text fields 'text to the appropriate properties of the reading, so that updates those values. for the purposes of our example changing the color is a bit more involved. the reading object can, and shoshould, determine which category the reading shoshould fit. A sophisticated widget might be able to bind its text color to a category like this, but we'll assume we don't have such a clever young thing. in this case controller takes over setting the variance field's text color directly.

As the example shows, the essence of a goodSupervising ControllerIs to do as little as possible. Let the view handle as much as possible and only step in when there's more complex logic involved.

One of the prime reasons to useSupervising ControllerIs for testability. assuming the view is hard to test, by moving any complex logic into the controller, we put the logic in a place that's easier to test. in order to run tests on the controller, however, we do need some form of view, so a test double is often in order. with the double in place, we don't have any need for UI framework objects in order to test the more awkward parts of the UI behavior.

This testability issue affects another demo-whether the Controller shocould access the view and its widgets directly, or through an intermediary. with An Intermediary we build a gateway for the controller. the gateway defines an interface for the Controller to manipulate. one implementation then adapts the window's interface while the other provides a stub for testing (you cocould also use a mock ). this is the same approach that you need for passive view.

Figure 3: using an intermediary between the Controller and the window.

The discussion so far suggests using flow synchronizationSupervising Controller, But this need not be the case. It is possible to use observer synchronization, but it needs to be modified so that it's the controllers that observe the model rather than the views.

When to use it

There are two main reasons to look into usingSupervising Controller: To separate out the complexity of an autonomous view, and to improve testability.

The separation advantage is that it pulls all the behavioral complexity away from the basic window itself, making it easier to understand. this advantage is offset by the fact that the controller is still closely coupled to its screen, needing a pretty intimate knowledge of the details of the screen. in which case there is a real question mark over whether it's worth the effort of making it a separate object.

The testability reason is the more compelling one. Usually people I 've talked to have found using some form of controller has made a big difference to making a UI that is properly testable.

If testability is your driver then the driving issue is how much behavior to leave in the view. passive view is a very similar patternSupervising Controller, But with the difference that passive view puts all the view update behavior in the controller, including simple cases. this results in extra programming, but does mean that all the presentation behavior is testable. the choice between the two depends on what kind of data binding support you have and whether you're happy to leave that untested by Controller tests.

A third alternative is presentation model. this again pulls most behavior away From the view, but leaves it to the view to synchronize all its updates. there isn't a great deal of the difference in test coverage between presentation model andSupervising Controller-Much of the choice (as with passive view) depends on personal judgments.

Significant revisions

19 Jun 06: first publication in development area of website.