Common Mistakes with Cairngorm.

I have been using Cairngorm (CG) for awhile now, on
various projects and teams with some fair amount of success. CG is great with the scalability and function it provides.

Working with various groups of developers there are few patterns of
mistakes that people can make with CG. I wanted to point out
a few that I thought might be helpful for you when deciding on the
architecture of your next Flex application.

Note: This article assumes you know CG and have used it on a few projects.
If not, please take a look at Introducing Cairngorm

from Adobe. It provides a solid guide intro to CG.

ViewHelpers/ViewLocator are depreciated:

This confused a lot of developers, me included. ViewHelpers in
CG made sense at first because they offered you a buffer from
having your model communicate with your view. It also allowed you a way to
communicate with any view at any location of your application by
accessing the view’s, ViewHelper through the ViewLocator.

The new recommended approach is allowing the power of Flex binding to
bind objects from ModelLocator directly to your view.

Now, it may sound like a step back from the original
implementation but it really does offer you a strong way to push data
from the model to views with Flex binding.

Organize your classes:

One of the biggest pet peeves is the way some people to depend too much on a
micro-architecture like CG and think that they can throw all other OOP
best practices out the window.

Once in a while you see the command package having every single
command in the root of the package. A good practice would be to
organize your commands into relevant packages, and even sub-packages,
if appropriate.

Your model and view packages should be just as organized. Try not to stuff everything in them -  keep them lean and organized.

For example, let’s say you have a list of commands associated with user
log-in and others for managing a shopping cart. Organize those into
two packages in the commands folder so other developers can easily
find commands associated with that section of functionality in your
application.

CG Events:

Cairngorm Events are used to notify your Commands. Developers sometimes create unnecessary custom events for every command. Your events and commands don’t have to be a one to one relationship. Adding all those extra objects for nothing more than firing an event can be a waste and add more to the clutter.

Some might say that they do so to store the event type, but you can easily place the static constant in your controller or just a base event object for the group of functionality.

Use Delegates:

Delegates aren’t required for a CG implementation, but they do provide
another layer of decoupling between your application and the outside
world. Delegates are nice during development because you can create
mock objects into your data until the services are ready.

Having the external communication in one centralized location is beneficial due to the simple fact that if an external service changes you can easily just replace the service without having to change any command or view.

Delegates can be organized in groups. For example, create one delegate object to house all the calls related to user modification. That way you have all the calls made to your API or web service relating to the functionality in one place. There is no need to have a delegate for every single related service call.

Not everything needs to go into CG:

So the point of a micro-architecture like CG is to allow a developer
to hang their code on this very light-weight framework. Developers can paint themselves in a corner because they feel that every object has to be tightly tied into CG. They dump every single data point into the Model or have complex data mining or algorithms sitting right into the command or delegate.

It is important as a developer to architect your application properly and allow pieces of your application to reside out of CG that don’t need to be there.

Summary:

I hope you found some of these points helpful in designing your next CG based application. I know once I started implementing some of these best practices it became apparent to me at how easier my applications would scale and how fast I could update certain sections of my code.