So far we’ve looked at possible unit test strategies for presentation models and supervising presenters. Now I want to turn my attention to the Autonomous View pattern. By leaving state and logic in the view, the Autonomous View pattern is arguably one of the simplest presentation patterns to understand and implement. But is it so easy to unit test?
In my last entry I took a look at unit testing the classes of a simple Presentation Model application. In this entry I’m going to turn my attention to a functionally-identical Supervising Presenter application. If you cast your mind back to my original investigation of these patterns you’ll remember that the main difference between Presentation Model and Supervising Presenter is that the former extracts both state and logic from the view whereas the latter only extracts logic. So in order to receive user events and manipulate view state in response to these events, supervising presenters maintain a reference to their corresponding view.
As mentioned in the introduction, I’m going to attempt to unit test my presentation model example application first. Of all the presentation patterns I’ve looked at, I’m expecting the presentation model to be the easiest to unit test.
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.
You may have caught my last series in which I looked at six different patterns for organising view logic in a Flex client. In this series I’m going to take the demonstration applications for three of those patterns and look at the changes required to effectively unit test them. The aim of the exercise is to gain an insight into how amenable each pattern is to unit testing and hopefully wrestle with some common unit testing challenges along the way.
Towards the end of last year I took a look at six contrasting patterns for organising presentation logic. Some of these patterns are well known and popular in the Flex community, others are very rarely discussed. If you know of any other presentation patterns that you feel are worth looking at more closely it would be great to hear about them.
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.
Code Behind is a somewhat vague term that means different things to different people. I believe it was originally coined by Microsoft to describe any strategy for separating logic from content in ASP pages. Using this broad definition it could be argued that the Supervising Presenter, Presentation Model and even the View Helper are all examples of the technique. So this interpretation of code-behind lacks the sort of precision we require to discuss it as a pattern.
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.
While looking at the Supervising Presenter and Presentation Model patterns it occurred to me that some people may find these concepts reminiscent of the View Helper pattern that enjoyed a spell of popularity in some Cairngorm architectures. Since the View Helper is now regarded as ‘not recommended’, I want to take a closer look at the pattern and try to understand why it may have fallen from favour.
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.
Like the Autonomous View, this is another one of Martin Fowler’s patterns. He calls it Supervising Controller, but suggests the alternative name of Supervising Presenter. I’m voting for the latter for the following reasons:
- 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.