Challenges

When attempting to unit test views directly, there are numerous challenges to overcome.

Challenge 1 – Isolating the views: Strictly speaking, to unit test an autonomous view class we should be creating stub or mock objects for all of the classes it collaborates with. But a typical autonomous view in Flex could collaborate with numerous Flex framework classes. In my example, the AlbumForm collaborates with three TextInputs, one Checkbox, and two Buttons; not to mention container classes like Form and FormItem. Stubbing all of these is no trivial task and not something I’m going to attempt. So strict unit testing of an autonomous view application is out.

A more sensible approach would be to treat each distinct autonomous view class as a "unit" for testing purposes, and assume that the Flex controls it contains are part of that unit. So I’ll create a unit test suite for AlbumForm and AlbumBrowser since these are distinct autonomous views, and when testing AlbumBrowser I’ll create a stub for AlbumForm.

Challenge 2 – Creating the view: When testing presentation models and supervising presenters I instantiated the "class under test" in my test suite’s setup method. But if I do the same for autonomous views, when I try to access a child of my view instance I get a null pointer exception. This is because my test code is being executed before the view’s CreationComplete event has fired. So to ensure that the CreationComplete event has been dispatched before my test runs, I have added an asynchronous setup method. This method instantiates the autonomous view, adds it to the display list and then uses the FlexUnit "addAsync" method to trigger the unit test code in response to the view’s CreationComplete method.

Challenge 3 – Simulating gestures: A further problem with unit testing my views is that much of their behaviour is driven directly by user activity. For example the change event of the TextInput class can only occur in response to user input. So I have the following options:

• Fake the event by calling dispatchEvent on the control and passing it a suitable Event instance that I’ve created and populated myself..
• Drive the control using the Flex automation library
• Bypass event dispatch and call the event handler directly from my test.

The first of these appears to be the easiest, so that’s the option I’m going with.

Challenge 4 – Stubbing the Alert class: The AlbumBrowser class displays an alert box when the user navigates between albums without saving their changes. I want to test this behaviour, but I don’t want to see pop-ups appearing during a test run. So I’ve extracted the pop-up behaviour into a separate class (called YesNoDialogue), and added a stub class for use during test runs.

Challenge 5 – Stubbing child views: I’ve already said I’ll create a stub for AlbumForm in order to test AlbumBrowser in isolation of AlbumForm’s logic. I’ve done something similar in my previous entries for Presentation Model and Supervising Presenter. In those examples I used a factory method to allow real classes to be substituted with stubs. This works great in ActionScript, but is there a way to swap a real view with a stub when the real view is declared in MXML? Well I gave myself a full 15 minutes to think of one, but nothing came to mind. So in order to stub my AlbumForm, I’m forced to abandon MXML and create my child view in ActionScript. This is a significant compromise.

Example Application

With these challenges overcome or worked around, I could successfully unit test the Autonomous View demo. The unit tested version of the application is available here; right-click to view the source. The test runner for the unit tests is available here.

Thoughts

This isn’t so much a tutorial on how to unit test an autonomous view application as an example of why you should avoid trying to. Although many of the challenges can be resolved or worked-around, one in particular presents a real problem. The autonomous view pattern is attractive because of its simplicity; and a large part of that comes from the convenience of MXML for declarative layout. By abandoning MXML in order to unit test, I am undermining the simplicity of the pattern.

Further work

There may be clever ways to stub views in MXML and I admit I didn’t spend much time looking at how to achieve this. If you’ve found an elegant approach for testing this pattern without abandoning MXML I’d be very interested to hear about it, but I don’t intend to investigate the topic any further myself.

Challenges

The first challenge when unit testing supervising presenters is the dependency they have on the view. Since I am trying to follow a strict unit testing strategy, I want my supervising presenters to be tested independently of other classes, including view classes. So I need to find some way to isolate my presenters from their corresponding views. Besides this unit-testing purism, there are other reasons for isolating my tests from the view:

• Views are generally relatively slow to instantiate and require a disproportionate amount of resources. Having to create views in order to test classes that depend on them may slow down the running of my test suites.
• Animation, deferred instantiaion and modal behaviour could make unit testing challenging.

There are probably many ways to decouple presenters from views, but I’ve decided to follow Martin Fowler’s suggestion of creating a "Gateway" between the view and the presenter. Each gateway will have two responsibilities:

• Act as a facade for a view. Presenters will access and manipulate the view via the facade.
• Observe the view for user events and invoke operations on the presenter.

Each view-dependent gateway will implement an interface to allow it to be substituted with a view-independent stub class for use during testing. This UML diagram illustrates the impact of the gateway approach on the original design.

The second challenge is the collaborative relationship between supervising presenters. In order to isolate one supervising presenter from another I’m going to use the factory method approach described in my previous entry.

Unit testing AlbumFormPresenter

The presenter for AlbumForm does not collaborate with any other presenter objects, but I do need to create a gateway class in order to isolate it from the view. I had to make a few changes to the architecture in order to slot in my gateway, and the end result is a gateway object between the view and the presenter called AlbumFormGateway. This gateway class implements the interface IAlbumFormGateway, so that it can be replaced with a test double called StubAlbumFormGateway. The test double does not require the real view, and the AlbumFormPresenter does not differentiate between the real gateway and the stub gateway because they both implement the same interface. So now I can unit test my AlbumFormPresenter class without needing an instance of AlbumForm.

Unit testing AlbumBrowserPresenter

I also need to create a gateway object for AlbumBrowserPresenter to decouple it from the corresponding view class. This is achieved in precisely the same way as for AlbumFormPresenter. So I’ve added an AlbumPresenterGateway, IAlbumPresenterGateway and StubAlbumPresenterGateway.

In addition to creating the gateway class, I also need to isolate the functionality of AlbumBrowserPresenter from AlbumFormPresenter. If you recall from my previous entry, a similar relationship existed between the AlbumBrowser and AlbumForm presentation models. So I’m applying the same factory method approach approach to allow the real AlbumFormPresenter to be replaced by a stub. The result is a new interface IAlbumFormPresenter, and a new stub class StubAlbumFormPresenter.

A further complexity for AlbumBrowserPresenter is the dependency it has on the PopUpManager. Rather than stub the PopUpManager class I have placed it on the ‘view-side’ of the gateway; so the presenter displays the pop-up by calling a method on the gateway.

Unit testing Album

Unlike the Presentation Model applicaton, the Album VO in the Supervising Presenter example doesn’t have any methods, so it doesn’t need to be tested. Or does it?

In order for my application to work the Album VO class does need to do one very important job: It needs to support binding. Should I write unit tests for bindability? Well strictly speaking I should, and perhaps I could use Tom’s EventfulTestCase for this. But I think I’ll look more closely at this another day.

Unit testing AlbumDelegate

As with the Presentation Model example, I’m not testing this class.

Example Application

The unit tested version of the supervising presenter demo application is available here; right-click to view the source. The test runner for the unit tests is available here.

Thoughts

The supervising presenter’s view dependency does make unit testing more challenging. The gateway approach appears to be a robust strategy for isolating supervising presenters from views, but it comes at a price. The gateway layer adds extra complexity to the application, and the gateways themselves cannot be unit-tested because they still have dependencies on views.

Further work

After going to the trouble of creating gateways I’m left wondering whether it would be simpler to create test doubles for my actual view classes and dispense with gateways altogether. To do this I would have to extract an interface for each view and then create standalone test doubles that contain identical framework controls. For this to work I would also need to find some way to create fake framework events for my presenters to respond to. I’m not going to attempt this because I now want to turn my attention to unit testing autonomous views.

Challenges

By extracting view state and logic from the view, presentation model classes do not have any dependencies on view classes. They do sometimes have dependencies on each other, so test doubles may be required to isolate the functionality in one presentation model from functionality in another.

Unit testing AlbumForm

The AlbumForm class is quite straightforward to unit test as it only collaborates with the Album value object. I’ve decided not to create a test double for the Album VO because of its simplicity. It only has too methods, and I suspect they will be difficult to simulate without duplicating their behaviour.

In the unit test for AlbumForm I have created tests for all of the public methods of the AlbumForm class. Many of the public methods require more than one test in order to exercise every path of execution.

Unit testing AlbumBrowser

The AlbumBrowser class is a little harder to unit test because it collaborates with the AlbumForm class. In order to isolate my AlbumBrowser unit tests from the functionality of AlbumForm, I’ve decided to create a test double for the AlbumForm class. To do this I’ve made the following changes:

• Extracted an interface from AlbumForm – In order to create a test double for the AlbumForm, I’ve created an IAlbumForm interface which the AlbumForm now implements. The test double ‘StubAlbumForm’ also implementes IAlbumForm allowing it to be used as a substitute for AlbumForm.
• Modified AlbumBrowser to work with any IAlbumForm implementation - Now there’s more than one way to do this, and I’ve used a factory method. The AlbumBrowser is modified so that it creates its instance of AlbumForm in a factory method (that’s just an instance method that is reponsible for constructing the AlbumForm). The factory method is marked protected so that it can be overriden in a subclass. In my AlbumBrowser unit test I’ve created a private subclass of AlbumBrowser that overrides the factory method to return an instance of StubAlbumForm*. My unit test for AlbumBrowser tests an instance of the private sub-class rather than AlbumBrowser itself. This allows me to test AlbumBrowser functionality in isolation of the AlbumForm class.
• Added a property to StubAlbumForm to allow me to control the flow of tests – The AlbumBrowser takes different actions depending on the result from the ‘changesToSave’ method on the AlbumForm class. In order to test these different paths I’ve added a ‘pendingChanges’ property to the StubAlbumForm that allows me to specify the return value of the ‘changesToSave’ method.

I’ve also captured these modifications in the form of a UML diagram, so take a look if none of the above makes any sense.

Together, these changes allow me to test AlbumBrowser in isolation of the AlbumForm class. Doing all of this may be considered overkill for such a small application, but it becomes important for larger applications with deeper hierarchies of presentation model instances and more complex collaborations.

Unit testing Album

The Album VO doesn’t collaborate with any other objects, so testing it is very easy. The unit test for the Album class covers the two public methods: clone() and equals().

Unit testing AlbumDelegate

Since this class is a fake delegate, I’m not going to test it. In real applications it will be necessary to create test doubles for delegates.

Example Application

The unit tested version of the presentation model demo application is available here; right-click to view the source. The test runner for the unit tests is available here.

Thoughts

The presentation model’s independence from the view simplifies the unit testing of application-specific user interface logic. The main challenge is isolating the functionality of one presentation model from that of another. I’ve chosen to use a factory method approach in my application, but other creational patterns could also be applied, as could some form of dependency injection.

Further work

The presentation model classes in this application are still not very well encapsulated. Many of the properties the view binds to are public properties; this simplifies binding, but undermines encapsulation. I’d like to tighten up the encapsulation on these classes, but that’s a task for another day.

*A similar approach in Java would be to use Anonymous Inner Classes inside tests or fixtures to create test-specific sub-classes (here’s an example from IBM). EcmaScript and consequently ActionScript do not support this language feature, so I’ve used a private class instead.

What is unit testing?

This isn’t an introduction to unit testing or a tutorial on how to get started with unit testing. So if you’re asking this question you may want to have a look at some of the links below. The test tool of choice for this series is Flex Unit as it is the one we use on our consulting projects. There are others out there, so feel free to shop around.

• Unit testing and Test Driven Development (TDD) for Flex and ActionScript 3.0
• How to use FlexUnit with FlexBuilder 2
• FlexUnit Basics
• The lost FlexUnit documentation
• FlexUnit articles in the Flex Cookbook

The plan

When looking at Presentation Patterns I started with the simplest pattern to implement, but for this series I’m going to start with the pattern that I believe will be simplest to unit test. So here’s the order of business:

1. Presentation Model
2. Supervising Presenter
3. Autonomous View

Why test view logic?

Applying a unit testing strategy to your user interface logic can have more than one advantage:

• Helps uncover defects early – This is the obvious one, unit testing should help you detect bugs as you develop your code. It won’t detect every bug, but it should provide an extra line of defence.
• Facilitates refactoring – Refactoring is something of a buzzword these days and you’re far more likely to hear people talking about refactoring their code than unit testing it. Refactoring is a structured technique for reducing duplication and redundancy in your code, but without automated unit tests it can also be a great way to add defects.
• Helps to communicate intent – Unit tests can help to describe the intended behaviour of a class. This is of particular importance in team-based software development, or for applications with long maintenance phases. Code commenting and technical documentation are still often favoured over unit testing, but it is debatable whether these are more reliable than a comprehensive suite of unit tests.
• Increases the focus on architecture – Adopting a unit test strategy forces you to think more about the architecture of your application. Perhaps most significantly, the need to test each class in isolation of its collaborators encourages a developer to code against interfaces rather than concrete classes. You’re also likely to see fewer global singletons and law of demeter violations in a unit tested application because of the increased emphasis on modularity.

Is this Test Driven Development?

Test Driven Development (TDD) or test-first development is a development practice in which unit tests are written before the code they test. The advantage of TDD is that the test is seen to fail before the code is written, and the code is then written to make the test pass. I’m not following a TDD approach in these entries because the applications I’m testing have already been written.

In my next entry I’ll take a look at unit testing my Presentation Model example.

Why did I want to do this?

Establish a base-line of terminology for future discussions

Over time, terms like View Helper and Code Behind have become somewhat vague. Discussions involving them often go awry because participants do not have a common understanding of these concepts. Having a "pattern language" is beneficial when investigating architecture, but only if the patterns are unambiguously defined. So in future discussions I want to be able to link back to this series if I happen to mention a presentation pattern in passing.

Increase my own understanding

Some of the patterns in this discussion have been applied on consulting projects past and present, while others are architectural curiosities that have piqued my interest. Building a simple application with each one has helped me to come to a better understanding of how they contrast. Before starting to develop the Supervising Presenter I thought it was very similar to the View Helper, but it turned out to be quite different. And despite never being entirely comfortable with the Code Behind pattern, it wasn’t until I saw it side-by-side with patterns like Presentation Model and Passive View that I started to understand the benefits of a more compositional approach.

Explore the possibilities with Flex

Knowing about architectural possibilities is only useful if your target platform is able to support them. Flex has proved itself more than capable of supporting all six of these contrasting patterns. Having said that, some of the patterns do make better use of Flex’s features than others. Both the Presentation Model and Supervising Presenter combine extract-class refactorings with elegant use of MXML bindings and declarative event handlers. On the hand, Passive View and Code Behind sacrifice these features in order to achieve a greater degree of ActionScript / MXML separation.

What Next?

Take a closer look at unit testing

Although I talked about unit testing throughout these discussions, you may have noticed that I didn’t actually do any. The very need to unit test could make or break a pattern, and can become a driving force for architectural decisions. Furthermore, the subject of unit testing is broad enough and important enough to warrant a series of blog entries to itself. So my next job is to look at how amenable some of these patterns are to unit testing.

Further exploration of presentation patterns

I kept the example application for this series very simple because I knew I would have to implement it six times, this is why many aspects of presentation behaviour mentioned in the introduction were not demonstrated. I can see real advantages of moving non-graphical concerns such as navigation, deep-linking and localisation out of the view, so I’d like to take a closer look at this in the future.

Take a look at integrations patterns

In RIA development projects, finding a way to organise your presentation logic in a way that meets your objectives is a great step forward, but not the only challenge. The way in which your application interacts with remote services is also extremely important. So what are the common integration patterns in the Flex world?

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.

Motivations

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.

Issues

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.

However, one of the most common methods for achieving code-behind in ASP and .NET uses inheritance: Presentation logic is extracted out of the view class, and into the view’s superclass. The technique has been brought over to the Flex world and is arguably one of the most talked-about and advocated presentation patterns. It is this "code-behind pattern" that I am going to look at today.

Key features

• Logic (and other "developer" stuff) is in an ActionScript superclass
• Layout (and other "designer" stuff) is in an MXML subclass

Motivations

Language Segregation

I think the primary motivation for the Code Behind pattern is the segregation of ActionScript from MXML in order to support a developer/designer workflow. The precise division of responsibilities between ActionScript and MXML varies across implementations. Event handler specifications are usually extracted into the ActionScript class, but there seems to be some difference of opinion on whether binding statements can remain in MXML. It is also unclear whether designers can be expected to configure declarative validation in the MXML file. In my example I have extracted event handlers, binding statements and validation into the code-behind class.

Unit Testing

I’ve not seen much discussion of unit testing Code Behind classes, but I suspect they may be more ‘testable’ than equivalent Autonomous Views.

Code-behind classes contain references to sub-views; so unit testing them is likely to require mock objects. Since instances of sub-views are instantiated by the MXML subclass, it will be necessary to find a way to inject suitable mock instances when unit testing the base-class.

In addition to having references to sub-views, code-behind classes also contain references to UI controls. Since Flex controls do not implement interfaces, it is unclear to me how they could be mocked in the traditional sense. I think further investigation is required to understand the issues here.

Issues

Why extract superclass?

With the exception of the Autonomous View pattern, all of the patterns I’ve looked at so far attempt to extract logic from view classes into a separate set of ActionScript classes. This kind of refactoring is often referred to as ‘extract class’. The Code Behind pattern is unique in that it attempts to extract logic into a superclass, a variety of refactoring known (somewhat unsurprisingly) as ‘extract superclass’. Generally speaking the extract superclass refactoring is applied to move functionality shared by two classes into a base class in order to reduce code duplication. But in the case of Code Behind, we only have one view class. So why use extract superclass?

Poor separation of concerns

By performing an extract superclass refactoring, the resulting ActionScript class is still very likely to extend one of the Flex framework components such as HBox, VBox, or Panel. So it is difficult to see any real separation of concerns. As with the Autonomous View pattern, the layout concern is still central to the class hierarchy and code-behind classes are unlikely to have a common editable base class.

Tight coupling

The two classes resulting from the code behind pattern are very tightly coupled. An inheritance relationship is arguably the most intimate of associations. In advanced architectures it may be desirable to have more than one logic class for each view (for example to provide different view behaviour for different user roles); this isn’t possible when the view extends the logic class.

Is MXML only for designers?

Perhaps I’m being selfish, but there are two very useful features of Flex that are only available in MXML:

• Bindings with curly braces ‘{}’
• Declarative event handlers

Whilst I could probably live without these two features, I’d prefer not to.

Example application

The example application demonstrates the Code Behind pattern; right-click to access the source.

Final thoughts

It isn’t clear to me why the Code Behind pattern favours inheritance over composition, and I think this is the main drawback to the approach. Although logic is extracted out of the view, the resulting code-behind class is still tightly coupled to the Flex framework. Furthermore by having the view extend the code-behind class, the view becomes very tightly coupled to the logic.

By favouring composition over inheritance, the Supervising Presenter and Presentation Model patterns offer improved separation of concerns and consequently greater flexibility. Neither of these patterns achieves the same degree of separation between MXML and ActionScript as the Code Behind pattern, but the next pattern I’m going to look at certainly does. It’s another one of Martin Fowler’s and it’s called Passive View.

The View Helper is loosely based on a similarly named J2EE pattern, but the purpose and realisation of the pattern within Flex applications is somewhat different to its server-side counterpart.

Key features

• State is (mainly) in the view
• Logic is (mainly) in the view helper
• The view ‘knows’ about the view helper
• The view helper ‘knows’ about the view

As with Supervising Presenter and Presentation Model, the View Helper pattern extracts logic from view components into ActionScript classes.

Motivations

Tracking down the original motivations for the View Helper pattern is more an exercise in historical research than technical investigation, but here are a few possibilities:

Mediation

Steven tells me the View Helper has its roots in RIA development using Flash. It was introduced to act as a mediator for views in an application. Back in those days, views were constructed as a hierarchy of movie clips. For these movie clips to find each other and collaborate directly they would need to know quite a lot about the structure of the view. Rather than duplicating this ‘knowledge’ around the view hierarchy, it was encapsulated within the view helper class. So when the structure of the view changed, only the view helper needed to be updated.

The problem the View Helper pattern addresses in Flash is less of a problem in Flex, because of the "flattening" effect composite view components have on the view hierarchy. But the mediator pattern is certainly relevant to Flex applications: both the View Helper and Supervising Presenter patterns perform mediation between UI components.

Language Segregation

Another justification for the View Helper pattern is to achieve a segregation of MXML and ActionScript. For some, this is to enhance readability or tidyness of the code, and for others it is to support some kind of designer / developer workflow.

Decoupling

In the days before the miracle of Flex bindings and the omniscient ModelLocator, it was necessary for Cairngorm commands to directly update views with the results of remote operations. In order to avoid coupling the commands to the views, the View Helper was used as an intermediary. The View Locator pattern was also employed to allow the view helpers to be ‘located’ by the commands.

Unit testing

As we’ve seen with two of our previous patterns (Supervising Presenter and Presentation Model), one objective is improved ‘testability’. From the perspective of the view helper, the reference back to the view will cause the same unit testing difficulties as apply to the Supervising Presenter. Dependencies in this direction could be loosened by having the view implement an interface, and coupling the view helper to the interface instead of the concrete view class. This would allow testing of the view helper with mock objects.

Issues

Libraries instead of classes

View Helpers are usually little more than ActionScript libraries for their corresponding views. In most cases they don’t form their own structure of collaborating classes or exist within a broader class hierarchy, and they cannot be really described as an architectural layer. Each one is just a file in which to hide away the logic for a particular view.

View helpers are lonely

If you take a look at the class diagram for the demo application, you may notice there are no direct associations between view helpers. So although the logic has been extracted from the view into a separate class, this new class must still rely on the view in order to collaborate with other classes. The lack of associations between view helpers severely limits their value as a means to separate concerns. This caused me some problems when coding the example, and I found myself with awkward statements like:

view.form.helper.album = album;

One way to avoid this issue would be to move some of the ‘setter’ logic back into the view. Another approach would be to introduce a singleton that would allow view helpers to be ‘located’ by other view helpers. Neither option is particularly satisfactory.

View creates the helper

Should the view be creating the helper? Giving this responsibility to the view reinforces the notion that the view is still in charge, and the helper is a subordinate. I tried to avoid this for the Supervising Presenter and Presentation Model patterns, favouring injection instead.

Example application

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

Final thoughts

The View Helper pattern isn’t a great distance from either of the Supervising Presenter or the Presentation Model patterns discussed previously. But it doesn’t seem to achieve the same benefits, and this may be because the motivations for the pattern have been forgotten or have gradually lost their relevance. As a mediator, the View Helper does not achieve the same separation of concerns as the Supervising Presenter: there is a bi-directional coupling between the view and the helper, and the helper must rely on the view in order to find and collaborate with other view helpers. By improving testability, the View Helper could be regarded as a step in the right direction, but as a refactoring it just didn’t quite go far enough.

Next up: Code Behind

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

• This pattern is a derivative of the Model-View-Presenter pattern rather than Model-View-Controller, so ‘Supervising Presenter’ seems a more suitable name.
• Due to excessive overloading, the meaning of the term ‘controller’ in UI architecture discussions has become somewhat vague.
• The ‘Presenter’ object is neither a controller in the J2EE / Model-2 / Cairngorm sense of the word, nor does it have much in common with the controllers from the original Smalltalk-MVC architecture.

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

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