This post is a follow-up to my post last week were I noted some of my initial reactions to the Cairngorm Framework.

When I look at the overview diagram of Cairngorm, I just keep hearing Eddie Vedder exasperatedly saying, “… It just doesn’t feel like we have evolved at all – in 20 years…” I will admit he might not have been talking about software (but I still love Pearl Jam – so whatever). Audio Here

After writing some code with Cairngorm I am feeling less critical. I think the structure provided by Cairngorm makes sense to some extent – at least more sense than the overview picture provided. I would still love to see a much flatter picture and resulting implementation. Either way, I figured I would throw out a few suggestions that I believe would improve the framework and the potential perception of future Java developer converts to Flex sure to check it out.

We all love patterns, and the value in them comes from the shared understanding of a given pattern. My largest hang-up with the framework is the naming of some of the components, and I am less than convinced that they all follow the patterns they are named after.

I don’t believe the “Front Controller” is true to the pattern (nor should it be). There are much better ways in Flex to accomplish the benefits articulated in the Front Controller pattern. In the Cairngorm code it is just a simple dispatch mechanism. To me, the only real value of MVC is addressing separation of concerns (SoC). This pattern needs to go by the wayside, along with the thin-client architectures we are striving to replace.

To the extent we do need some dispatch mechanism to address the SoC and a level of true decoupling, I actually think that Cairngorm falls a bit short. In the store example application, the ValidateCreditCardCommand uses the executeNextCommand function to chain commands by hard coding the next event. Certainly, this is where we could gain value from a central dispatch infrastructure. Also, the controller doesn’t really do anything except map an event to a command within the class file (there is little-to-no benefit in this).

So, in terms of trying to providing a constructive suggestion, I think Cairngorm should rename the “Front Controller” to “dispatcher,” and provide a more robust mechanism for mapping, and the chaining of multiple commands to a given event. In Flex, we really just need M & V or M-V-D (dispatch).

In addition, the Service Locator pattern could also stand to be renamed. Although, it is of far less consequence than other issues. I have had a bit of a hang-up here in explaining Cairngorm to other Java developers evaluating Flex, as it doesn’t really do any lookups per the pattern. It really just encapsulates the client side configuration for accessing remote services. So, once again the name could be considered misleading, and the Cairngorm framework should consider renaming the Service Locator.