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.
- 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.
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.
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.
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.
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.