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

  • State is in the presentation model
  • Logic is in the presentation model
  • View observes the model and updates accordingly
  • The view “knows” about the presentation model
  • The presentation model does not “know” about the view

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

7 Responses to Presentation Patterns – Presentation Model

  1. Christoph says:

    Hi Paul,

    Thx for the overview on Presentation Model and Supervising Presenter. Its a great way to be able to cover much more of your logic through unit tests. We use a quite similar architecture at our current project.

    Regarding your implementation of the Presentation Model:
    Wouldn´t it be better to let the view access their Presentation Model through a PM-Factory so not all Presentation Models are instantiated on startup?

    All the best,

    Christoph

  2. AlexU says:

    yes, you could certainly do that. I’d depend it on how your views (MXML) work. If you’ve got dynamic views that are created at some later point in time, also create the presentation models in that way. I’d found it useful in the past to let the presentaiton model reflect the hierachy of your view components to some extend.

    i.e. a parent MXML view knows about their children, but the children usually doesn’t know about their parent and would simply dispatch events. I’d also move the event dispatching part to the presentation model layer and unit test for events.

  3. Tim says:

    Hi,

    First off, thanks for a very interesting series. Great to see these patterns implemented so you can learn from the source.

    A question about your use of the observer pattern: why not use custom events instead? The syntax of the observer pattern seems almost identical to a simple event listener and it doesn’t seem to alter the encapsulation of the model object. Just have the model implement IEventDispatcher and register the view as a listener. Wouldn’t that cut down on code and keep consistency in your method of communication in both models and views?

  4. Marcus Stade says:

    We’ve been using this kind of model for a while (although we’ve used a different name for it and actually didn’t know about it’s existance before). It’s really quite awesome since it not only decouples state handling from the view itself but also makes you realize that all you need to save the state of an application (for instance in a cookie) is the presentation model itself. This means that you can throw away views any which way you want and only need the presentation model to recover the view.

    Also, it’s very easy to connect different views to each other without having them know about each other at all, they just communicate with the model. Update the model from one view and the change is immediately propagated in the connecting view(s). This pattern is actually quite useful and powerful once you think about it. The view essentially becomes more or less completely decoupled and can be changed almost daily if you wish.

    However, I hadn’t realized the implications of unit testing the model to in essance test views. This is a recent revelation for me and definately something that I’m exhaustively going to further examine.

    Anyhow, very nice, clear and concise writeup of the pattern. Also, the sample is quite nice. The Observe and Observer classes are very cool, I hope you don’t mind me borrowing them! =)

    Thanks for sharing!

  5. Elad Elrom says:

    I have used some of the theory to implement the Presentation Model in Cairngorm framework using custom Ant scripts:
    http://elromdesign.com/blog/2008/12/13/cairngorm-and-the-presentation-model-using-ant-scripts/

    Maybe we should consider similar approach with the Cairngorm plugin.

  6. Shlomi says:

    Hi
    its very nice article and sample applications. i do have a problem with all the samples now running in the net regarding the presentation model.
    1. the examples are simple , where do you write the code when the application get really big and ugly
    2. since the logic and the state are in the presentation model, what exactly is the role of the commands/controller here. are they just using the delegate to fetch data if so , they are redundant. i don’t think this presentation model is aligned with MVC so much, who is the controller ?

  7. Flavy says:

    Hi there,
    Thanks for this article. But i have one question. What is if i have a PM(1a) which holds a PM(1b),then i have a other PM(2a) which hold a other (2b). when i change a state in 1b how can i make this state syncornized in the PM 2b.

    In other word HOW communicate PMs with each other?

    Greetz Flavy