Flex Pasta

The Pros and Cons of Cairngorm

Cairngorm seems to be the architecture pattern of choice for flex. If you’re new to flex it certainly is a good way to keep you organized in your code layout. As you grow your code base flex can turn into spaghetti quickly if you don’t start out with a solid framework.

Here is what your typical Cairngorm structure might look like:

• Business - Contains the various services for Remote Object calls, Web Service calls, etc
• Command - Handles the formation of the Request/Response of these service calls.
• Control - Here lives the one and only Cairngorm controller class. Home of headaches and heartbreaks, this is where you map your events to command classes. The headaches and heartbreaks come into play when you forget to add your new event and commands to this class. When you finally figure it out, your mind repeats idiot idiot idiot idiot over and over again for a few minutes. But this goes to the root of the main con I see with Cairngorm…..keep reading.
• Domain - If you are using Remote Objects, you probably want to keep the matching actionscript classes in one place.
• Event - When a user interacts with your super cool app, events are fired off that cause other layout changes based on the user request. Biggest problem with Cairngorm is that you have to implement a clone method for each event, another piece of painful overhead.
• Model - Holds the data and states for the app.
• View - All datagrids, etc, that make up the user interface.
• Vo - Stores other objects similar to domain that organize data for easy use in the view.

So this all looks like good fun right???? Well yes, until your tasked with writing an app to takeover the world!! Well ok, maybe not take over the world but the app is going to be BIG! Lets just say your going to have 100 remote methods divided into 10 different parts of your app. Which since I made the math simple means you will have 100 event classes, 100 command classes, 10 model classes, 10 business classes, and a long control class, not to mention probably hundreds more view classes.

What does this mean for me?

1. Order more ram for your pc. Java can compile one class and keep trucking, but actionscript into a swf requires more chips than a game of poker. 2GB minimum RAM if you are setting out on a big project.
2. Start looking at a lot of busy work, creating the 200 event/command classes needed. Some people have even created Cairngen, a code generator for all those classes. This is my main issue with the framework. If your have to write a code generator for the framework, then the framework needs to be simplified!!

How to simplify Cairngorm?

Get rid of all the command classes, and almost all of the event classes. Continuing from the theme above: 100 remote methods in 10 remote classes(10 methods per class). Here are the steps to simplify:

1. Create 10 interfaces in actionscript that will match your methods in your 10 remote classes. Put these in the “business” folder.
2. Create a new folder called “request”. Create 10 classes called ‘RemoteServiceRequest’, each of which implement your 10 interfaces. This replaces what would be the “execute” method of a command class.
3. Create a new folder called “response”. Create 10 classes called ‘RemoteServiceResponse’, each of which implement your 10 interfaces. This replaces what would be the “result” method of a command class.
4. Create a new folder called “fault”. Create 10 classes called ‘RemoteServiceFault’, each of which implement your 10 interfaces. This replaces what would be the “fault” method of a command class.

So we are now looking at 40 classes in all and far less overhead to create them, add to them, and edit them because they all implement the interface classes you created. It is also more clear what remote methods you are calling, no guessing as to what command class goes with which remote method. More importantly, your code is still clear and has and organized framework. You still use the model in this framework, storing state and data objects. When you call a remote service, and you need other view functionality changes, you can still dispatch a normal flash event for this. This approach outlined is a significant departure from Cairngorm. In fact, it deserves its own name. Let’s call it the Penne Framework. Look for more about the Penne Framework on my blog in the future(and maybe even some real live code!).

Conclusion

The Cairngorm framework is a well thought out architecture for flex applications. It provides good separation of responsibilities for your code. For larger projects, it can create a lot of overhead in the number of classes needed to support this approach. The Penne Framework provides a simplified alternative for large scale flex projects. Look for more on the Penne Framework in the future!!