Wednesday, January 18, 2012

Supervising Controller as Design Pattern for JSF and other View Frameworks with Data Binding Facilities

Design patterns for user interfaces have become numerous and somewhat ambiguous. Precise and up-to-date descriptions and distinct advice are hard to find. But there is a best practice, at least for large enterprise systems based on JSF (and similar view frameworks) if a tool for automated view tests is available: Supervising Controller. The adoption of this pattern leverages the data binding facilities and keeps controller and view very compact. Only the view implementation becomes dependent on view technology. This article will describe all elements of the pattern and the interaction in detail. And I will explain advantages and disadvantages over other patterns.

A little bit of history
In the 80's and 90's, development of user interfaces was based on the Model-View-Controller (MVC) pattern and had been time-consuming. Fortunately, the capabilities of modern view frameworks like JSF made much of the hand-written code obsolete. As a consequence, Model-View-Presenter (MVP) and the similar Presentation Model (PM) evolved. Later on, Microsoft propagated Model-View-ViewModel (MVVM) as specialization of PM for Windows Presentation Foundation (WPF) and Silverlight.[1] Around the same time, Martin Fowler decided to split MVP into Passive View and Supervising Controller.[2] See Fowler's excellent article on GUI architectures for more details on the correlation of all these patterns.[3] Jeremy D. Miller continues Fowlers work and is currently working on a book[4] on this. His wiki[5] is not online right now, but his blog series[6] from 2007 comprises 20 detailed posts with C# code samples. Oleksiy Shelest published an in-depth description of all these patterns in 2009 with class diagrams and implementation examples in C#.[7]

The Supervising Controller in detail
The Supervising Controller pattern is sometimes also called Supervising Presenter. It consists of a model, a view interface, a view implementation and the Supervising Controller itself. Figure 1 shows these classes and their dependencies. The classes in this diagram provide a screen with a timetable editor and a service to store the associated data. A user can view all his existing appointments in the timetable.

Figure 1: Example for the Supervising Controller Pattern (Click to enlarge)

The responsibility of the model is to provide data for the view.

In very simple cases it is identical to the Transfer Object (TO) provided by the service facade of the business layer. For more complex models, the model takes a references to the TO and converts it into an appropriate representation for the view. In my example, the TimetableEditorModel references several AppointmentTOs. Additionally, it adds the specifications for the columns of the timetable, e.g. column title and column alignment.

Note that the model here is not a Presentation Model[8] because it does not comprise the complete screen state. By the way: Presentation Model requires a synchronization technique between view and Presentation Model. If Model-driven Development is used and the mapping code can be generated, Presentation Model is a great pattern to cover the complete screen logic by unit tests.

The view is an interface to access the widgets of the user interface. Each implementation of the view supports a specific view technology, for example JSF. The different view implementations are the only parts of the presentation layer that have dependencies to view technologies.

The responsibilities of the view implementation are:
  • Holding the model
  • Creating the controller
  • Performing callbacks to the controller on UI events
  • Acting as backing bean for a screen (in case of JSF)
The responsibility of the view interface is to expose the necessary widgets to the controller.

Supervising Controller
The Supervising Controller takes care of all complex view logic. All simple parts of the view logic are left to the view, the view framework and the data binding. For a simple form, the Supervising Controller is very lean.

The Supervising Controller is independent of the view technology. This allows for unit testing without the need of the view technology. If different view technologies must be supported, the controller logic can be reused.

The responsibilities of the Supervising Controller are:
  • Mediation between business layer and presentation layer
  • Handling all complex view logic
  • Updating the model with business data
The advantages over a Passive View[9] are that the Supervising Controller leverages of the data binding facilities of the view framework and that it leads to less methods in the view to be mocked.

The only disadvantage is that unit testing without the actual view does not cover the data bindings. We accept this because automated view tests, for example with Selenium RC or WebDriver, can cover it.

For models with hierarchical data in an object structure, data binding becomes more complex. One might favor Passive View over Supervising Controller in this case.[10]

When it comes to JSF
Many JSF tutorials use only one backing bean per screen. Their approach combines model, view and controller and therefore mixes business logic and view technology. The controller and the model cannot be reused for a second view technology then, e.g. for a native smartphone app.

When properly separating model, view and controller, the view implementation is the only backing bean for the screen. The objects are created in the following order:
  1. JSF instantiates the view implementation.
  2. The view implementation creates the controller instance.
  3. The Supervising Controller calls the service to obtain the transfer object. The controller creates the model instance, fills it with data from the transfer object and provides the model to the view.
  4. The view implementation holds the model and uses it for the JSF data bindings.
Sometimes, developers suggest turning the Supervising Controller into a managed bean to use dependency injection for service access. But this makes the Supervising Controller dependent on JSF and therefore undermines future re-usage for other view technologies. I would rather recommend an additional managed bean as helper class for the Supervising Controller POJO.

For a more detailed adoption of the Supervising Controller in JSF, see Adam Bien's in-depth article.[11] In his description, he calls his example Passive View, but I'm quite sure that it is a flawless instance of Supervising Controller. For a C# implementation with WinForms, have a look at Jeremy D. Miller's version.[12] The ShippingScreenPresenter of his of Supervising Controller example has only to interact with IShippingService. By contrast, the ShippingScreenPresenter of his Passive View example has to wire each single field to the screen.[10]

Best practice
When data binding and a tool for automated view tests are available, the Supervising Controller clearly comes off as winner for all non-hierarchical data. It keeps controller and view simple and improves testability. Table 1 shows a side-by-side comparison of this pattern and its competitors.

CriterionSupervising ControllerPassive ViewPresentation Model
Data binding fully leveraged
Tool for automated view tests fully leveraged
Complete view state easily accessible
Hierarchical view data well supported
Model-driven development fully leveraged
Table 1: Comparison of the three patterns in question

  1. ^ Smith, J. MSDN Magazine February 2009. "WPF Apps With The Model-View-ViewModel Design Pattern" [cited 2011 Dec 29]
  2. ^ Fowler, M. Development of Further Patterns of Enterprise Application Architecture. "Retirement note for Model View Presenter Pattern" [cited 2011 Dec 29]
  3. ^ Fowler, M. Development of Further Patterns of Enterprise Application Architecture. "GUI Architectures" [cited 2011 Dec 29]
  4. ^ Miller, J. "Presentation Patterns: Designing Maintainable Desktop Clients" [cited 2011 Dec 29]
  5. ^ Miller, J. The Shade Tree Developer. "Presentation Patterns Wiki" [cited 2011 Dec 29]
  6. ^ Miller, J. "The Build Your Own CAB Series Table of Contents" [cited 2011 Dec 29]
  7. ^ Shelest, O. The Code Project. "Model View Controller, Model View Presenter, and Model View ViewModel Design Patterns" [cited 2012 Jan 30]
  8. ^ Fowler, M. Development of Further Patterns of Enterprise Application Architecture. "Presentation Model" [cited 2011 Dec 29]
  9. ^ Fowler, M. Development of Further Patterns of Enterprise Application Architecture. "Passive View" [cited 2011 Dec 29]
  10. ^ Miller, J. "Build your own CAB Part #4 – The Passive View" [cited 2011 Dec 29] 
  11. ^ Bien, A. JavaSPEKTRUM February 2008. "Visuelle und wartbare Entwicklung von JSF mit EJB 3" [cited 2012 Jan 18]
  12. ^ Miller, J. "Build your own CAB Part #3 – The Supervising Controller Pattern" [cited 2012 Jan 18]

No comments:

Post a Comment