« September 2007 | Main | November 2007 »

October 22, 2007

Presentation Patterns - Presentation Model

The next pattern I want to look at goes a step further than the Supervising Presenter by moving logic and state out of the view. Once again discussed by Martin Fowler, the Presentation Model has its roots in the Model-View-Controller (MVC) pattern.

A presentation model is an ‘abstraction’ of a view. In other words, the model represents the behaviour and state of a view, without getting involved with any of that messy graphical stuff. The view represents a projection or rendering of the model onto the screen. When changes occur in the presentation model, the view updates itself on-screen.

Martin Fowler describes two variants of the Presentation Model, one in which the view observes the model, and another in which the model observes the view. I will be looking at the former in this discussion because in Flex it is far easier to set-up observer relationships from MXML views to ActionScript models.

Key Features

Model-view synchronization is usually achieved by applying the observer pattern, and in Flex this can be realised with MXML bindings. Although the view ‘knows’ about the underlying model, the model is unaware of the view; compare this with the Supervising Presenter, where the opposite applies.

Furthermore, in a Presentation Model application, view state and logic are both extracted from the view into the model. Again this is in contrast to the Supervising Presenter, in which only logic is moved out of the view; and the Autonomous View, in which logic and state remain in the view.

Motivations

As with the Supervising Presenter, the motivation behind the Presentation Model is to address issues with the Autonomous View approach:

Testability

Since Presentation Model classes are fully decoupled from the view, the logic they contain is much easier to test. This puts the Presentation Model ahead of the Supervising Presenter, since the latter has a reference back to the view. Writing FlexUnit tests for presentation models should be no more difficult than for other kinds of model classes.

Improved separation of concerns

If each presentation model represents an abstraction of a view, then together they can be thought of as a model for an entire user interface. Common presentation behaviour can be refactored into base classes and shared throughout the model. I can see enormous potential here, which I hope to explore in the future.

Issues

How much logic and state should be extracted?

As much as possible. Most non-graphical presentation concerns are candidates for extraction into the model. Presentation concerns that have a strong graphical component (such as animation) and concerns that are closely coupled to the underlying framework (such as drag-and-drop) may be best left in the view. Coding this logic into the model would require too much knowledge of screen size, layout and the kinds of UI widgets being used.

Some logic is likely to remain in the view

As mentioned above, logic that is directly coupled to graphical concerns will need to stay in the view. The Supervising Presenter does not have this restriction, because it is allowed to ‘know’ about the view.

The view also needs to be 'smart' enough to know which methods to call on the presentation model in response to input events.

Example application

The example application demonstrates the Presentation Model pattern; right-click to access the source.

Final thoughts

Both the Supervising Presenter and Presentation Model allow you to create a separate class hierarchy for your application-specific behaviour. The former uses the view to store UI state, the latter places the state in the same class as the logic. By being decoupled from the view, the Presentation Model pattern offers more convenient unit testing and improved decoupling from the view. However, the model's total ignorance of the view means that some of the more 'graphical' behaviour cannot be extracted.

Up next: View Helper

Posted by paulw at 8:15 AM | Comments (7)

October 13, 2007

Presentation Patterns - Supervising Presenter

Like the Autonomous View, this is another one of Martin Fowler's patterns. He calls it Supervising Controller, but suggests the alternative name of Supervising Presenter. I'm voting for the latter for the following reasons:

Key features

Unlike the Autonomous View, the Supervising Presenter aims to extract non-trivial presentation logic out of the view into a separate class known as a Presenter. The view retains some autonomy, and controls in the view can still bind directly to underlying domain or value objects.

One very important feature of the Supervising Presenter pattern is that the view is unaware of its associated Presenter, but the Presenter is aware of the view. This is a trait inherited from Model-View-Presenter and is a principal difference between MVP and MVC. Each Supervising Presenter must observe its associated view for user events and coordinate the necessary view / model updates in response.

Motivations

Two reasons for adopting the Supervising Presenter pattern would be to address the drawbacks of the Autonomous View pattern:

Easier to test

Separating complex presentation logic into a separate class should facilitate unit testing. But there is one big fly in the ointment: The Supervising Presenter has a dependency on the associated view. So to test a Supervising Presenter you either need instances of your actual views, or 'mock' objects that simulate the behaviour of the views. If you use your actual view components, you’ll probably experience the same unit testing problems as you would with an Autonomous View

Improved separation of concerns

Following the Supervising Presenter pattern should yield an application-specific class hierarchy that is separated from the view classes, but coupled to them. Common presentation concerns can be refactored into Presenter base classes, and this should help to reduce code-duplication and improve consistency across an application.

Issues

How much logic do we extract?

The question of how much 'supervision' a view needs is difficult to answer. The Supervising Presenter pattern exists half-way between Autonomous View (which we have already seen) and a pattern known as Passive View. The Passive View pattern extracts all logic from the view into a Presenter class, including bindings. For my own example, I have extracted any logic that cannot be expressed by a simple binding statement. I have also left the validators in the view, as they can be configured declaratively. But the lack of clarity on how much logic to extract may lead to inconsistencies on larger development projects.

Mock objects? What mock objects?

The use of mock objects is a common strategy when unit testing, but creating mock objects to simulate Flex views may not be a trivial task. Then again, once it is done the resulting mock-object library could be reused on other projects.

Logic is extracted but 'state' remains in the view

The Supervising Presenter pattern extracts presentation logic from the view, but leaves presentation state in the view. A purist may argue that this is only a partial refactoring: In an OO architecture, state and associated logic are usually encapsulated within the same class. Dogma perhaps, but in my experience strong encapsulation does facilitate refactoring and reuse.

Example application

The example application demonstrates my take on the Supervising Presenter pattern. As with the Autonomous View demo, there's additional information accessible via the View Source option.

Final thoughts

Despite the issues described above, I do think the Supervising Presenter deserves more attention. It holds the promise of improved unit test coverage, and may help to decrease code-duplication in an application. So far I haven’t encountered a Flex application that uses the Supervising Presenter pattern, so I guess my example must be the first. Perhaps you know different.

Up next: Presentation Model

Posted by paulw at 9:10 AM | Comments (6)