Tom Sugden: The Trend Towards Inversion-of-Control Frameworks in Flex

« EventfulTestCase: a FlexUnit extension for testing event dispatching | Main | A Declarative Approach to Flex Popups »

July 6, 2009

The Trend Towards Inversion-of-Control Frameworks in Flex

Last year I wrote three chapters about the Cairngorm MVC framework for a new Flex book, Professional Flex 3, published by Wrox Press. Cairngorm has been widely adopted on enterprise projects, so it was important to explain its workings and cover the best practices and common pitfalls. If you’re a developer who moves between clients and projects, this is important knowledge to have. However, with more time and pages, I’d have liked to devote similar attention to the other Flex frameworks now available.

Over the last few years, the Flex framework space has become well served with alternatives to Cairngorm, each offering their own take on the challenges of RIA development. While Cairngorm is rooted in design patterns from the Java enterprise world, some of the newer framework creators have taken a fresh approach, reflecting on the language features and special capabilities of ActionScript and the Flex SDK, then building from the ground up, taking advantage of features like event bubbling, declarative MXML and metadata.

Inversion-of-Control

In these new frameworks, there has been a trend towards the inversion-of-control (IoC) or dependency-injection pattern. There is a good reason for this, since this approach decouples the objects of an application, so they can change independently of one another and be tested in isolation. Applying IoC can make it easier to restructure a user interface, substitute the service integration layer, and refactor the models containing the logic and state of your application, amongst other benefits.

For those new to the concept, IoC means passing (or injecting) the dependencies for a class into that class, instead of creating the dependent objects within. The behavior of a class can then be controlled by passing in different types of objects; an inversion of the traditional approach. When interfaces are extracted from these dependencies, the technique becomes more powerful, because the class is decoupled from any concrete classes. The interfaces can be implemented in different ways to achieve different outcomes and can be substituted for testing purposes.

An example of this design is found in the Tree component of the Flex SDK. The Tree uses the ITreeDataDescriptor interface to determine whether the items in its data provider are branch or leaf nodes.

public interface ITreeDataDescriptor
{
    ...
    isBranch(node:Object, model:Object = null):Boolean
    ...
}

This interface decouples the Tree from the actual type of objects inside the data provider. By substituting different implementations of ITreeDataDescriptor, it can be made to render all kinds of objects in tree form. This inversion of control makes the Tree a more flexible component than it would be if a single data descriptor of fixed type was created internally.

Inversion-of-Control Frameworks in Flex

A number of IoC-based frameworks have emerged for Flex to support the development of loosely-coupled applications. They typically provide a way to configure the main objects used by the application (models, services, etc.) and to specify the dependencies between them. These frameworks are sometimes known as IoC containers, where the container is the part of the framework responsible for instantiating objects and setting-up (or wiring) the dependencies. In some cases, the container assumes further responsibilities, such as managing the life-cycle of the objects (calling initialization and disposal methods) or routing messages from one object to another.

To give a potted history, two of the earlier arrivals were Prana and Parsley, both of which were inspired by the popular Spring framework from the Java world. They used XML files for configuration and singletons for extracting pre-configured objects from the containers into Flex views. The generation that followed, including Swiz and the lesser-known Flicc, were lighter weight and took more advantage of features of Flex. Swiz took the most radically simple approach, defining objects (or beans) directly in MXML and injecting them automatically into views wherever a special metadata tag was placed, while Flicc provided a novel set of MXML tags for object definition, event handling and view injection.

Since then all of these frameworks have been evolving. Prana has become Spring ActionScript, an extension of the official Spring Platform, while Parsley picked up some tricks from Swiz and Flicc and broadened its feature set to include messaging, module integration and extensibility points. Swiz too has gained new capabilities while remaining distinctly lightweight, like prototype object instantiation (a.k.a. non-singletons) and more flexible event mediation with bubbling events and metadata. A more detailed comparison of these frameworks together with sample applications is due to be published soon on Adobe Devnet in an article written by my colleague, Ed Eustace (link will be added after publication).

Conclusion

The frameworks space is in good shape for Flex. Established MVC frameworks like Cairngorm and Pure MVC, that prescribe certain design patterns and structures, have been complemented by a slew of new frameworks1 centered around inversion-of-control. When applied correctly, these enable developers to write more loosely-coupled software that can be changed and tested more easily.

However, inversion-of-control is a very general approach that can be applied in different ways. Questions remain about the best way to use it for building Flex applications. For advanced developers, the freedom afforded by these new frameworks is a benefit, since their experience enables them to make wise judgements about how to structure the layers of an application (view, model, control, integration, etc). For less experienced developers, however, the pattern alone provides little guidance and mistakes can easily be made. Since software project teams tend to consist of multiple developers with different levels of experience, it is important to establish guidelines around the use of an IoC framework for a team to deliver efficiently.

The variety of approaches and competition between frameworks is in the interests of Flex developers and end users. It’s giving us better solutions to the recurring problems of RIA development, allowing us to focus on what is special and distinct about our projects, rather than the basic plumbing. There are some opportunities for consolidation and there's no one-size-fits-all solution at present, so technical architects need to evaluate carefully and choose the best framework for a particular situation, given the technical considerations and also the makeup of the team.

Progress looks to be steady with the current selection of frameworks, but perhaps new capabilities are needed for Flash Player and the Flex SDK to enable the next major leap forward?

1 The Mate Flex Framework and probably others have been unfairly overlooked in this blog post. Although not positioned as an inversion-of-control container, Mate does provide a means of dependency injection together with a neat set of declarative MXML tags to structure and coordinate a Flex application.

Coming Up

In a future post, I’ll write in more detail about Parsley 2, the second version of the Parsley Application Framework. Parsley has arguably the richest feature set of the current generation of frameworks, yet it also has a simple elegance. The blog post will focus on two of the features that currently distinguish it: module integration and loosely-coupled messaging.

Posted by tsugden at July 6, 2009 8:35 AM

Related Entries

Comments

Post a comment




Remember Me?

(you may use HTML tags for style)