« January 2007 | Main | October 2007 »

September 30, 2007

Presentation Patterns - Autonomous View

So as I mentioned in the introduction, the first pattern I'm going to look at is known as 'Autonomous View'. Of all the patterns I'll cover, this one is likely to be the most familiar to Flex developers. Although Martin Fowler coined the name, the idea behind the Autonomous View pattern has been around for quite some time. For the Flex framework, the Autonomous View represents the de facto architectural pattern. If you're building your first Flex application, you'll probably be following the Autonomous View pattern without even knowing it.

Key features

• State is in the view
• Logic is in the view
• That’s about it...

An Autonomous View architecture is one in which the presentation logic is implemented directly in the view. Autonomous Views effectively manage their own state and interact with each other where necessary.

The vision at the core of the Autonomous View pattern is one of smart reusable components glued together to form a hierarchy of composite views. In extreme cases, business logic and interactions with remote-services are also implemented directly in the views. But many Autonomous View architectures do attempt some extraction of this kind of logic into separate classes for use by multiple views.

Motivations

I think this pattern is attractive because of its simplicity. As I’ve mentioned previously, an absolute Flex beginner is most likely to follow the Autonomous View pattern without knowing it. Many of the examples in the Flex documentation also follow the Autonomous View pattern.

Issues

Difficult to unit test

Fowler discusses the difficulties with unit testing Autonomous Views, but he isn't talking specifically about Flex. I can see a few possible problems with unit testing views implemented in this way:

• Common unit testing techniques such as mock objects, dependency injection and factory methods are not catered for by MXML. The use of these strategies to facilitate unit testing is likely to undermine the convenience of MXML for creating composite views.
• Use of Flex ‘manager’ classes such as the pop-up manager will cause some undesirable behaviour when running unit tests.
• Some events can only be triggered by user interaction.
• The use of features such as effects and states may complicate the writing of unit tests.

As I mentioned in the introduction, I’m not looking specifically at unit testing for this series. It is an important subject and requires a great deal more investigation, so I hope I can look more closely at the topic in the future.

Poor separation of concerns

Typically a composite view will be a sub-class of one of the container components. In most applications, it is likely that different views will sub-class different layout containers, and some will extend navigators and other Flex controls.

So the views within an application do not share a common base-class, or at least not one that the developer can easily change. Take a look back at my list of presentation concerns and you will see that 'layout' is but one of many. Placing the layout concern at the centre of your application's class hierarchy may limit your refactoring options when you come to implement other equally significant features. The inability to refactor common presentation functionality into base classes is likely to result in code duplication and behavioural inconsistencies.

Example application

The example application demonstrates my take on the Autonomous View pattern. I’ve included some developer notes and even a class diagram (don't get too excited). These can be accessed by right-clicking on the application and viewing the source.

Final thoughts

The Autonomous View pattern is one of the simplest presentation patterns and arguably the most mainstream in the Flex community. But on larger applications with multi-faceted presentation concerns, the line between simplicity and naivety does begin to blur. Many of the other presentation patterns I’m going to look at aim to address the limitations of the Autonomous View approach.

Next up: Supervising Presenter.

Posted by paulw at 9:11 AM | Comments (2)

September 23, 2007

Presentation Patterns - Introduction

A recurring theme on forums like flexcoders is the issue of user interface architecture within Flex applications. Rich-client applications developed using frameworks like Flex are something of a departure from 'traditional' web applications, so the architectures employed for such applications will inevitably differ. But not so long ago we were comparing the new concept of web-application development with that of 'traditional' rich-client applications and arriving at very similar conclusions. We have come full circle, from rich-clients to web-clients and back again. So what lessons can we learn from the 20 or so years of rich-client development preceding Web 1.0? And are there web-application patterns that translate across to the rich-client world?

Martin Fowler is one of the most vocal commentators on UI architectures and he describes a number of contrasting patterns over on his website. Many of the patterns he discusses are aimed at the organization of presentation logic.

What is presentation logic?

There’s a rich variety of application 'concerns' that could be covered by the term 'Presentation Logic'. Here are a few possibilities:

• Layout
• Animation / Rendering
• Dynamic view creation (eg. pop-ups)
• Responding to user input
• Progressive reveal / disclosure
• Navigation behaviour
• Deep linking
• User input validation
• Display formatting
• Localisation / Internationalisation

Some of these are more closely related to the graphical environment than others.

What's the plan?

I want to take a closer look at Martin Fowler's presentation patterns, and I'm also keen to review some of the more popular patterns in the Flex world. To help me compare and contrast the patterns, I'll build the same example application using each one. This application is based on Fowler's album-browser example. I've 'Flexed' it up a bit, but it is still very simple - no remote services, no domain models, no business objects and no frameworks (except Flex). I will touch on the subject of unit testing when comparing architectures, but in the interests of blog-entry-brevity I'm going to leave a full analysis of 'testability' for another day.

The Patterns

• Autonomous View
• Supervising Presenter
• Presentation Model
• View Helper
• Code Behind
• Passive View

First up: Autonomous View

Posted by paulw at 12:25 PM | Comments (1)