Presentation Patterns – Conclusions

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.

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?