Agile Enterprise Application Development with Flex

Final Framework Selection Considerations

If you are a Flex architect or a development manager in charge of selecting a third-party Flex framework, ask yourself these questions: “Do I want to use intelligent objects that encapsulate most of the framework functionality, or do I prefer to deal with simple objects and do explicit coding for each instance? Will I have senior developers in the project team? Do I need to modularize the application to be developed? Do I trust code generators?”

After answering these questions, take a detailed look at the implementation of several frameworks, assess the benefits each of them brings to your application, and pick the most appealing one that will give you confidence that it—given the project’s size/nature/deliverables/available human resources—has the least probability of failing.

Always keep in mind that your application may grow and you’ll need to redesign it into modules. Will your selected framework become your friend or foe in a modularized application? In general, if you are going with modules, you need a multilayered framework and intelligent registration services that are written specifically for the task.

Cairngorm, Mate, and PureMVC are architectural frameworks that utilize global objects. These may simplify project management by providing a structure and separating developers’ work on the Model, View, and Controller. All these singletons, managers, and event maps are a way to establish communication between the application parts. By making this process more formal, you can build much smaller chunks, communicating with each other, and in your mind the more formal process will yield better maintainability. On the other hand, it will create more parts in your application that require maintenance and testing.

Clear Toolkit is an application framework that consists of a mix of enhanced components and code generators. Its goal is to make the development process more productive by substantially reducing the need to write code manually.

If the word global gives you goosebumps, but you are uncomfortable with code generators too, consider Joe Berkovitz’s MVCS approach (see References) as a middle ground between the two. This may work better for medium to large teams that would have no access to code generators and data-driven/factories-based architecture.

This book targets enterprise developers whose main concern is data processing. But there are legions of Flex developers who do not care about DataGrid and the like. They are into the creation of small visual components and do not need to use any application frameworks. For example, if you Google image viewer Cairngorm, you’ll find an example of a small application to display images built with this framework. This is clearly overkill and an example of bad practice, because if you are the only developer working on a small one-view application, introducing any architectural framework is plain wrong. For these kinds of applications, all you need is the Flex framework and possibly one or two self-contained components.

Large projects are different animals. Six months into the project, the functional specification may change. This can happen for a variety of reasons, for example:

• The business analyst realizes that she made a mistake.

• The business process changes.

• Another department needs some of your application’s functionality.

• Another line of business has to be handled by your application.

If this happens, commands need to be amended and recoded, views redesigned, and events integrated with a different workflow. Now you are thinking to yourself, “Why didn’t I go with code generators that could’ve made my application more agile?”

Using code generators and components is a way to get you through the “implementation” part faster while giving you maximum flexibility on the “design and functionality” part. If you don’t have 80 percent of your application built in 20 percent of the time, you will be late with the remaining 20 percent.

Flex itself is more of an application framework. It is not a library of patterns, but rather a set of objects that are built to communicate and react. The Flex framework itself uses code generators. The key here is automation of implementation tasks by minimizing the amount of manually written code. That is done by explicitly checking the “related” objects for specific interfaces. By not adhering to the implementation of these interfaces, the external frameworks require serious application development effort to support them.

After rebuilding Café Townsend, we decided to compare the sizes of the produced .swf file. We’ve been using Flex Builder 3’s Project → Export Release Build option with all default settings. These are the results:

Cairngorm	409 KB
Mate	368 KB
PureMVC	365 KB

The total size of the Café Townsend application produced by Clear Toolkit is 654 KB on the client and 30 KB of Java JARs (Java ARchives) deployed on the server. The size is larger, but this application includes full CRUD functionality; Cairngorm, Mate, and PureMVC don’t. And you’ve had to write just a dozen lines of code manually. This is a reasonable size for an application that has full CRUD functionality.

Of course, you can further reduce the size of the business portion of the Café written with any of the frameworks by linking the Flex SDK as an RSL.

When making your selection, consider the benefits you’ll be getting from the framework of your choice. From the learning curve perspective, none of the reviewed frameworks is overly difficult to master. You may spend a day or two with the manuals. But ask yourself, “What will be different in my project development if I use this particular framework?” Are you adding a small library to your project that helps you organize your project better, but still requires you to write a lot of code? Or are you adding a larger library that makes you write less code and be more productive?

Of course we are biased—we created Clear Toolkit to help us develop the types of applications we work on with our business clients, and it serves us well. Before making your final decision on a framework for your application (especially if it’s not as small as Café Townsend), ask yourself one more question: “If three months down the road I realize that I’ve selected the wrong framework, how much time/money would it take to remove it?” The answer to this question may be crucial in the selection process.

If you decide to use one of the architectural frameworks, it doesn’t mean that you can’t throw in a couple of useful components from Clear Toolkit or other libraries mentioned in the following section. You can also find some brief reviews and recommendations of third-party libraries and tools that will make your Flex ecosystem more productive.