The Flex Application Frameworks SmackDown (sorta)
The Selecting the Right Flex Application Framework post provided a summary comparison of the Flex application frameworks out there, highlighting the ones I thought were the “heavyweights” a Flex developer should focus on. The purpose was primarily to help you make a quick, easy, but well-informed decision, without looking at the code.
But many of us wish to look under the covers and see a detailed comparison of the frameworks. So I took Adobe’s Flex Builder 3 Getting Started tutorial example of a simple Flickr photo search and re-implemented it in Cairngorm, PureMVC and Mate.
No Framework
But before we discuss each framework, let’s quickly go over the problems that the frameworks are trying to solve. All Flex application frameworks have been created, because there are problems with implementing a Flex application without one (or, of course, with another framework).
If you take a look at the Code Files in the tutorial, you’ll see that the application doesn’t really need a framework, because it’s simple and straightforward. However, oftentimes, applications are just the opposite. So implementing a complex Flex application, without a framework and following the model described in the tutorial, will require the following:
- Separation of Concerns. Of course, the major rationale for using the framework is to separate the code based on its roles/responsibilities, i.e. model, view, controller. The advantages of which I won’t discuss further. Read Wikipedia. In any case, without a framework, the data, the business logic and the interface are mixed inside the FlickrRIA application.
- Data Sharing. Data, e.g. the photoFeed, needs to be shared to other screens in the application. It will not be best practice to expose the variables in different pages for other pages to access. Think spaghetti, but not for eating.
- Service Sharing. The HTTP Service and the like, e.g. the photoService, needs to be reused in other functions of the application, as well as the logic for using that service, e.g. the requestPhotos() method. Similar dilemma as with data sharing.
- Unit Testing. Testing must be easy to do. Automation is highly recommended. It can still be done without a framework, but it is difficult with the logic embedded in the Flex components.
Cairngorm
For all 3 frameworks, the development process starts with implementing the Photo value object. Beyond that, the frameworks differ.
Flickr Example Using Cairnorm (Flex project archive, ZIP)
Cairngorm addresses the difficulties in the absence of a framework with recommended best practices and the framework. Ease of testing and maintenance are derived from the separation of concerns.
- Model. Data is encapsulated and shared via the singleton ModelLocator, and is bound to the Flex components of the application.
- View. The View is made up of different visual Flex components in the application. It has two jobs: 1) dispatching events to request data or invoke actions on the backend and 2) watching for Model updates and updating the interface as needed.
- Controller. The Controller is implemented via the FrontController. It manages which command is invoked when an event is dispatched from the View.
- Business logic is encapsulated and spread out in Commands. It invokes the service (via delegates), handles the results, and updates the Model.
- Delegates add an extra layer of indirection between the application (client) and the server. They locate the service, invoke it and pass the necessary parameters.
- Services are encapsulated and shared via the singleton ServiceLocator.
I found Cairngorm really easy to learn and work with. With its wide support and defacto standard status, it almost always is the chosen framework. It’s good for medium to large development teams of varying skill levels in Flex and ActionScript.
However, there are a few disadvantages with Cairngorm.
- The ModelLocator can get huge and unwieldy; depending on how large your application is and how much data it keeps. To resolve this, I have seen using more than one ModelLocator to separate, say, the business data from the presentation data. But it still won’t be fun to handle merge conflicts with everyone updating it, if you’re in a large team.
- Extending the CairngormEvent for each event to encapsulate the event name ID and data was not too pleasant. I would imagine it’s easy to end up with duplicate event IDs in a large application (which is why a naming convention would be vital). I suppose you can create a generic Cairngorm event, but the data parameters wouldn’t be type-checked.
- Lastly, I wasn’t in favor of referencing the ModelLocator in all of my Flex components. I favored passing a data reference from a parent component to keep my view components as reusable and un-Cairngorm-ish as possible.
PureMVC
Flickr Example Using PureMVC (Flex project archive, ZIP)
PureMVC addresses the difficulties similar to Cairngorm with a few more layers of indirection.
- Model. Data is encapsulated and spread out in Proxies. These are referenced singletons. The Model handles interaction to the data access layer in persisting or retrieving data. In the code, I used the Proxy and Delegate pattern. No huge model locators found here!
- View. The View is implemented with Flex components and Mediators. The mediators run interference between the view components and the rest of the application. The View listens to events, sends notifications to request data or invoke an action, and receives notifications to update the visual components. The view components do not have any PureMVC-specific code and are reusable.
- Note that events do not need to be customized. The mediator retrieves the necessary data from the view component and passes it to the command.
- Events are, in effect, replaced by notifications — similar to a Flex event. Of course, there is no type-checking for the parameters.
- Controller. The Controller is hidden from the developer, but maintained the mappings between notifications and commands.
- Commands, like in Cairngorm, contain the business logic. But for data persistence and/or retrieval, they defer to the Proxies.
- Unique to PureMVC is the Façade. It is a singleton that initializes the Model, View and Controller components. All components can be accessed through the façade, as well as all notification and/or event IDs.
PureMVC resolves a lot of the aspects I didn’t like about Cairngorm. It is good for complex applications, with a lot of common components, e.g. forms-based applications with workflows. And it works well for medium to large development teams.
However, it does have a few disadvantages:
- PureMVC cannot rely on data binding innately. Manually updating the data on the view from the mediator could get annoying in a larger application. I suppose that is the “sacrifice” that must be made in making the view components purely portable, without any knowledge of PureMVC. However, because of this, I began to question, how often do I need it to be portable? Apart from this exercise?
- It’s more complex than other frameworks. Therefore, it does incur a steeper learning curve than others. It may not be too difficult for a developer who knows Java, for example. But complexity and flexibility can breed more architectural mistakes.
Mate
Flickr Example Using Mate (Flex project archive, ZIP)
Mate responds to the challenges of having no Flex application framework in a simple, “indirect” way. It is a “tag-based, event-driven Flex framework”, but can facilitate an MVC implementation.
- Model. Mate doesn’t provide specific model components, but enables the data sharing and encapsulation with the use of cached generators. In examples, they call these managers.
- View. The View is implemented with Flex components, which handle event dispatching for data retrieval and/or method invocation. Similar to PureMVC, the view components are highly reusable, since they don’t have knowledge of Mate.
- Controller. The Controller is configured via the event map, the core of Mate.
- Event handlers are defined in the map to specify what needs to happen when certain events are dispatched. It can support a variety of handlers, such as HTTP service invokers, web service invokers, command invokers and method invokers. In combination, these comprise the business logic triggered by the dispatched event.
- Instead of binding view properties directly to the Model, Mate uses injectors. Injectors are also defined in the event map to set properties from a source (in the Model) to a target (in the View). Similar to event handlers, injectors observe changes from the Model to trigger updating the View.
Mate also resolves a lot of my issues with Cairngorm, but is simpler overall than PureMVC. It is still unable to take advantage of data binding, but I prefer injectors to setting data through code.
Mate would work well for complex applications and is suited for small to large development teams. And unlike other IoC Flex frameworks, it provides more meat behind the event handlers.
Note: The embedded code files have comments that contain more details about each ActionScript class/component. It explains what needs to be created/updated for new functionality and what are the base objects. I have also included a “simplistic” sequence diagram (well, I tried as best I could to make it simple) of the event flows for each framework, when a photo search is performed.
source: http://www.summa-tech.com/blog/2009/02/27/the-flex-application-frameworks-smackdown-sorta/
StumbleIt! 
November 29, 2009
Social comments and analytics for this post…
This post was mentioned on Twitter by huongnt2: The Flex Application Frameworks SmackDown (sorta) http://blog.tuvinh.com/the-flex-application-frameworks-smackdown-sorta/...
--Reply