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:
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.
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.
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").
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.
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.
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—
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
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.
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.
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
Swiz also provides dependency management through a custom metatag called
Swiz is simple to use and does not impose a predefined structure onto your project. Through its
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.
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.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.
This article is written by Jeremy Wischusen and licensed under a Creative Commons Attribution-Noncommercial 3.0 Unported License.
Technical Articles >