Choosing a Flex framework

Recently, I've been doing a good amount of interviewing for positions as an Adobe Flex developer (freelance, to clarify—in case my day job boss happens to read this). In just about every interview, the subject of Flex frameworks eventually came up (typically, Cairngorm). I would explain that although I was aware of the existence of these frameworks, I had never really had any use for them. This decision seemed perfectly reasonable to me, but those conducting the interviews were not so impressed. Tired of losing projects because of my "lack of experience" with Flex frameworks, I set out on a mission to learn as much about them as I possibly could.

As luck would have it, the next meeting of the local user group was covering the topic of Flex frameworks—specifically, Cairngorm, Mate, and PureMVC (you can view the presentation here ). I had heard of all these frameworks from regularly listening to the Flex show podcast but was not really aware of how they worked or the differences among them, which brings me to the purpose of this article.

This article provides a summary of the most popular frameworks currently available for Flex so that you can make the most informed choice possible regarding which framework best suits the needs of your team or project. It covers the Cairngorm, Mate, PureMVC, and Swiz frameworks. I chose these frameworks in particular because they have been covered by the Flex show podcast and/or have been presented at conferences such as 360|Flex.

Cairngorm is the oldest and best known of the Flex frameworks. It is actually a micro-architecture—that is, a collection of design patterns that have proven to work well with one another. Cairngorm borrows heavily from the world of Java development and focuses on three key areas: handling user actions, encapsulating server interactions and business logic, and managing the state on the client and representing that state in the user interface (UI).

Building a project in Cairngorm involves breaking your application into several packages and extending the Cairngorm classes. Here are the major sections and classes of a Cairngorm project:

• The ModelLocator—a singleton that acts as a data repository—represents the state of the program. The singleton nature of the class ensures that all your program components are accessing the same data.
• The ServiceLocator is another singleton that acts a centralized location for storing services such as HTTPServices. Again, because this class is a singleton, all your program components will be accessing the same services.
• Business logic is encapsulated in command classes that implement the command pattern. These classes represent the logic that responds to user events.
• Events are handled by the FrontController class, which executes the appropriate command class for that event. Each user event that the program can respond to must be registered with this class along with its corresponding command class.
• Delegate classes are used as proxies for accessing and responding to remote services.

Strengths

Cairngorm is well known in the Flex community and, as a project on Adobe's Open Source site, is well supported and has an active community of developers who continue to work on it. Also, it borrows proven strategies from the Java development world and has been successfully used to create many large-scale projects. Finally, it is well suited for team development, because it provides a highly structured methodology for creating applications that allow distribution of tasks.

Weaknesses

Perhaps the most common criticism leveled against Cairngorm is that it requires you to write a lot of classes. In Cairngorm, each event maps to a command; therefore, you have to write a command class for every event your program can trigger. Additionally, you must write any other classes that the command must use, such as delegates. This can quickly turn into a large number of classes for even a modest-sized application.

Second, because Cairngorm implements its own method of handling events, it can complicate the built-in Flex event model. It also has some limitations. Because each event must have its own command class, you are limited to one responder per event. Also, Cairngorm events do not bubble, so if you want to notify things higher up the container hierarchy, you will have to do that yourself.

A third common criticism is the framework's reliance on global singletons, which can make modularization and unit testing difficult. Although you can break up the model among several singletons to make these processes easier, the extra work required can complicate the process.

Resources

• Cairngorm developer documentation
• Developing Flex RIAs with Cairngorm microarchitecture – Part 1: Introducing Cairngorm (Steven Webster and Leon Tanner, August 2008)
• Example Cairngorm project

The Mate framework

Mate is a tag-based, event-driven framework. Tag based means that it is implemented entirely in MXML. It is event driven in that the central focus of the framework is to make it easier to define who responds to events.

There are only two basic requirements for creating a project using Mate: You must have one or more events, and you must have an MXML file called an event map—that is, a simple MXML file included in the main application file. It defines the events you want to listen to and how they should be handled. You must have at least one of these files, but you can use multiple event maps, if necessary.

Mate also implements the idea of dependency injection—sometimes referred to as the Hollywood principle, or "don't call us, we'll call you." Objects are constructed in such a way that the data they require is provided to them or injected into the class. In other words, the classes don't call out to get data ("don't call us") but rather are passed the data they need ("we'll call you").

Strengths

Mate promotes loose coupling through its use of dependency injection. Because components do not rely on global singletons, they are freer to acts as independent agents. Mate does not keep you from using Flex's built-in event model, nor does it limit you to a single response for each event as Cairngorm does. Mate's MXML files and tags are straightforward and easy to use, and if you get stuck, the documentation is good and there are plenty of code examples on the site.

Weaknesses

Mate is MXML only. So, if you are one of those developers who like doing everything in Adobe ActionScript classes, you're going to have to adjust your normal routine. Because Mate does not define much of a structure for your application, it's left up to you to define. Hence, you will have to do your own team coordination to ensure that all your developers are coding in a compatible manner. Finally, if you happen to work with Adobe LiveCycle Data Services ES, be aware that Mate does not currently handle the data management that LiveCycle Data Services ES offers.

Resources

• Mate documentation
• Example projects
• Podcast interview with Mate framework creator Laura Arguello

The PureMVC framework

Although it is used for Flex, PureMVC was not actually designed as a Flex framework. The creator of PureMVC wanted the framework to be language agnostic. In fact, if you visit the site, you will see that there are implementations and code examples for a variety of languages.

PureMVC centers on the Model-View-Controller (MVC) pattern, with the stated goal of separating a project into model, view, and controller tiers. These tiers are represented by three singleton classes—Model, View, and Controller—with a fourth singleton called the Façade that is designed to facilitate communication among the tiers and act as a central repository for accessing their public methods.

Much like Cairngorm, creating a project using PureMVC involves dividing your project into several packages, then implementing your classes by extending the framework classes. PureMVC has the addition of the Façade class, which acts as the main entry point for the application.

Strengths

Like Cairngorm, PureMVC is a well-established framework and has a large and active community supporting it. It is also well suited to team development, because it provides a well-defined structure for how applications need to be created, standardizing coding across developers.

Weaknesses

Because it relies on singletons, PureMVC is prone to many of the same criticisms leveled at Cairngorm. It is not specifically a Flex framework, so it does not take advantage of the features of MXML. Like Cairngorm, PureMVC has its own method of handling events, and it can make working with the standard Flex event model more difficult. PureMVC is a fairly complex framework and has a relatively steep initial learning curve. Unless your team is familiar with it, training new employees can increase production time.

Finally, like Cairngorm, the PureMVC framework requires the creation of many classes, which can increase production time and project size.

Resources

• Documentation and licensing
• Example project
• Podcast interview with PureMVC framework creator Cliff Hall

The Swiz framework

Swiz is an inversion of control (IoC) framework that provides methodologies for simplifying event handling and asynchronous remote method calls. The main focus of the Swiz framework is to provide a true MVC paradigm in a simple, effective manner. Unlike Cairngorm and PureMVC, it specifically steers clear of imposing Java patterns and does not impose any predefined folder structure.

Creating a project with Swiz involves telling the Swiz framework about your application components. At its core, Swiz is a centralized factory pattern. Components are loaded into this factory through a utility class called the BeanLoader. When the application starts, the factory handles the instantiation of your components.

Swiz also provides dependency management through a custom metatag called Autowire. The Autowire tag is a method of defining dependencies among classes that Swiz then handles for you.

Strengths

Swiz is simple to use and does not impose a predefined structure onto your project. Through its Autowire dependency-injection system, it—like Mate—promotes loose coupling between components and manages dependencies for you. Also like Mate, Swiz uses built-in Flex event handling while providing help in such key areas as facilitating global event dispatching through the use of an internally referenced singleton.

Weaknesses

Again, like Mate, Swiz does not define much of a structure for your application—that's left up to you to define. Hence, you will have to do your own team coordination to ensure that all your developers are coding in a compatible manner.

Second, because it uses custom metatags, additional steps may be required to set up a project—for example, setting a few extra compiler arguments. These steps are not difficult, but it is something that the Swiz framework requires that the other frameworks don't. The documentation specifically mentions Flex 2 users, so this may not be an issue for versions later than Flex version 2.

Resources

• Documentation and examples
• Podcast interview with Swiz framework creator Chris Scott

Making your choice

Although by no means exhaustive, the information provided here in combination with the resources should be enough for a basic understanding of the methodologies, strengths, and weaknesses of each framework. So, how do you go about choosing one of these frameworks over another?

Perhaps the first question to ask is, do I need one? Flex and MXML provide a very robust methodology for rapidly building applications. The reason I held off so long on using a framework is that it seemed to me that it would require more work to adapt what I was trying to do to fit the framework's methodology than just using the Flex framework. To me, a framework should be something that makes tasks easier and increases productivity—not something I use just because I can or because I think it makes me a better developer for doing so.

That said, in one of the phone interviews I mentioned at the beginning of this article, after giving my explanation of why I had chosen not to use a framework, the interviewer responded, "I have to work in a large team. Surely you can see that I need some sort of framework." After giving it some thought, I do see what he means.

One of the benefits of using a framework is that it standardizes how things are coded. In other words, if programmer A and programmer B are working on two parts of the same project using the same framework, you can be pretty sure that the code they write is compatible. So perhaps another question you need to ask yourself is, how much structure do you want imposed?

The frameworks examined here vary a great deal in how much predefined structure they require. If you're working with a large team, you may want more structure imposed than if you're working on a project by yourself. It may be that the hit you take on production time and project size creating all the classes necessary for one of the more structured frameworks is offset by facilitation of a team work environment and the code consistency that the predefined structure provides. In contrast, if you're the only developer working on a project and you just need something to make life easier and speed up development, then perhaps you want to go with one of the frameworks that doesn't impose as much structure on your project.

So, it would seem that choosing the right framework—or choosing not to use a framework at all—is really a function of the goals of the developer and the environment in which the project will be created. The best advice I can give is to be honest with yourself about what you and the project require. I know that after doing my research and writing this article, I am much more open to the idea of frameworks, and I see that they do fulfill certain needs.