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.

2 comments so far

Add Your Comment
  1. Great article,

    why my right click don’t work on the exemple app?

  2. Hi Paul, thanks for this series on view patterns. Very enlightening, and great work in converting MF’s writing into practical examples to share and compare.

    I have to say, that I use presentation models myself, since I love bindings in mxml, and rightfully so, but also as a way to be able to manipulate state in a presentation abstraction for a view while being aware of both the model and view, without either aware of my proxying the binded data. I can trap for conditionals during complex state cchanges this way without ruining my view with logic for the state concerns.

    I’m wondering if we’re still missing one more pattern though - one that allows for inheritance instead of composition as in code behind, but with the purpose of having a base class that can be extended to handle commonalities amongst views for a proper implementation of extract superclass refactoring.

    Any hope there?

    Once again thanks, and nice working with you in the States, even if it was for a short time.