Presentation Patterns – Passive View

Like the Supervising Presenter, the Passive View pattern is a derivative of Model View Presenter (MVP). Martin Fowler split MVP into separate patterns to highlight two common approaches for realising MVP.

The Passive View pattern also has some similarities with Code Behind since both achieve a complete separation of ActionScript and MXML.

Key Features

  • State is in the view
  • Logic is in the Presenter
  • Presenter observes the view
  • Presenter updates the view
  • Presenter ‘knows’ about the view
  • View does not ‘know’ about the Presenter

The key features of Passive View are identical to those of Supervising Presenter. The difference between the two patterns is the degree to which logic is extracted from the view. Views in a Supervising Presenter application are allowed to ‘observe’ domain or value objects in order to display information, but views in a Passive View application are managed entirely by their presenter object.

The Supervising Presenter pattern lends itself to User Interface frameworks that have synchronisation features (eg. bindings in Flex), by allowing controls in the view to synchronise directly with underlying domain or value objects. The Passive View pattern prohibits this kind of behaviour in the view, so synchronisation between the view and the data model is managed by the presenter class instead.


The motivations for the Passive View are similar to those of the Supervising Presenter and Presentation Model:

Easier to test

By moving all behaviour out of the view, the Passive View pattern is likely to afford the maximum unit test coverage of all the patterns I’ve looked at. The presenter class has a reference back to the view; so mock objects will be required to test it.

Improved Separation of Concerns

As with the other extract class refactorings, the Passive View pattern can help improve the separation of concerns in an application. By favouring composition over inheritance, Passive View achieves a greater degree of decoupling from the Flex framework than the Code Behind pattern. Presenter classes do not need to extend from Flex containers.

Language Segregation

By moving logic out of the view, the Passive View pattern can achieve similar developer / designer workflow objectives as Code Behind. The resulting view class is free from event handler specifications, binding statements and script blocks.


I think all of the issues identified for Supervising Presenter also apply to the Passive View. Rather than repeating myself, I’ll just refer you back to that discussion.

Reduced role for MXML

As I suggested when discussing the Code Behind pattern, I don’t believe MXML is just for designers. Although it is primarily targetted at describing the look of an application, it also offers features that support developers. Keeping MXML for designers means developers do not have access to MXML bindings and declarative event handler specifications. This isn’t the end of the world and developers will adapt, but it does mean that some of Flex’s more powerful features are no longer being used.

What about declarative behaviour?

Some presentation behaviour can be achieved declaratively in MXML; effects, transitions and validators are all examples. Whether Passive View permits this kind of declarative logic in the view isn’t clear. It is probably safe to leave graphical behaviour in the view and drive state changes from the presenter if necessary. Non-graphical behaviour such as validation is probably best moved into the presenter class since it is likely to be more closely related to the underlying data model.

Example application

The example application demonstrates the Passive View pattern; right-click to access the source.

Final thoughts

The Passive View pattern goes a step further than Supervising Presenter by placing additional constraints on the autonomy of the view. But what interests me most about Passive View is the way in which it achieves similar goals to the Code Behind pattern through the use of composition rather than inheritance. For me this is a reminder that there is usually more than one way to solve a particular problem, and that the popular or mainsteam approach may not always be the best option.