I have written favorably about both Cairngorm and PureMVC, and this has led a number of people to ask which framework I prefer. Rather than make a blanket statement that one framework is better than the other, it seems more profitable to take a few moments to discuss some of the strengths and weaknesses of each.

Let’s start by emphasizing that the two frameworks share a number of strengths. Both of them provide conventions that, once learned, enable you to build complex applications faster. Both of them lend themselves (in varying degrees) to team development. Both of them promote some level of code reuse. Both of them help you make applications that are easy to maintain and extend. Both of them will enable you to build applications that any experienced Object-Oriented developer will be able to get up to speed on very quickly. Both of them give you complete control over event flows. (When using native Flex events, you need to be aware of bubbling, and whether there is any native Flex code that is also listening for the event you’re dispatching, but each of these frameworks addresses this issue - PureMVC implements a publish/subscribe system with its notifications, and Cairngorm uses CairngormEvent/CairngormEventDispatcher.)

Having looked at what the two frameworks have in common, let’s now take a look at what makes them different. Since we’re talking about Flex frameworks, I thought it would be fun to put the comparison matrix in an AdvancedDataGrid component:

You can open and interact with the matrix here. (Building it wasn’t as much fun as it should have been, but I’ll address that in a future post.)

I’m sure there’s much more that could be said, and I hope that you’ll add your thoughts to this discussion. If you don’t want to post your comments/questions here in the blog, feel free to contact me directly.

I promised to post a follow-up to my comments on Jeff Vroom’s presentation at MAX, so let me get to it before too much time passes.

There are different ways of representing the properties of complex objects. For example, let’s consider the pickup truck class. Every pickup has a cab (where the people sit) and the bed (where the people put their stuff). There are certain properties of the pickup that are really specific to the cab (for example, the number of people it can seat, and whether or not the rear window slides). Likewise, there are properties that are specific to the bed (fleetside or stepside, number of tie-downs, etc.). We could represent the pickup truck such that the class includes all of these properties in a hierarchy.

Another way to represent the pickup truck is to use discrete classes for the bed and the cab. In this way, we can encapsulate the cab’s properties and functionality in the Cab class, and the bed’s in the Bed class. We then associate each instance of the PickupTruck class with an instance of the Cab class and an instance of the Bed class. This results in a more flexible, extensible, and maintainable design.

When using LiveCycle Data Services (LCDS), there are specific advantages to using these managed associations rather than lumping everything together into hierarchical values. If we put all of the components together into a single hierarchical class, then LCDS treats it as a blob, so that the entire class instance is updated every time a change is made to any property. For example, if we change the value of cab.isAirConditioned from false to true, then all of the tables that provide data for our PickupTruck class are updated. However, if we use managed associations and change the value Cab.isAirConditioned, then only the table that provides Cab data gets updated, so it is less resource-intensive.

Using managed associations with LCDS also provides advantages for lazy loading. On application startup we could load all of the data for our PickupTruck objects but just load the IDs of the Cabs and Beds. Then we would pull the detailed Cab and Bed data as needed.

In short, Jeff affirmed that managed associations are preferred as long as IDs are available for the referenced objects. If the Cab and Bed tables don’t have IDs, then you may need to pile everything into the Pickup class. Otherwise, it’s better to write separate classes.