Cairngorm++

Call me a junkie, that’s fine, but this stuff works. I’ve said many times in the past that the whole purpose of using design patterns, code frameworks, and application architectures should be to reduce the code I write (as time progresses), make an application easier to extend, and reduce the cost of turnover.

After quickly learning what the Cairngorm architecture had to offer, I noticed several gaps that needed to be filled. One of which was the inordinate amount of files that are created using the base patterns (which I alleviated with my abstract classes for Event, Command, and Delegate). Another gap is that it doesn’t have a view mediator. That’s the one feature from the PureMVC framework that I actually was a huge fan of.

Mediators

You see, PureMVC uses a Mediator pattern in order to provide a mechanism by which views could interact with the business logic, as well as with each other, while remaining ignorant of the man behind the curtain. Keeping the views decoupled from the model is good – especially with my apps – because subtle changes to the data model happen often, and while a good part of that is handled in the business logic, it often bubbles up to the UI model as well.

I am a Command, I am an Island

Another value feature that other frameworks have is that ability for a View – via a Mediator – to actually know if a Command was successful or not. Gasp! With the base Cairngorm implementation, the only way to perform an action on success of a Command was in the Command itself. Very bad, otherwise you end up with situations that call for SaveProjectAndReloadModelCommand in which you do one action and then immediately call another Command, and SaveProjectWithNoModelReloadCommand for when you don’t need to do the second Command.

A Command should be as insular as possible. It should never directly call another Command.

Responseful Commands

My way around this was to implement a function callback feature in the Event and Command abstract classes.

When an Event is dispatched from a View, the name of a local function is passed as an argument. The Command consumes this function reference and then runs it if the execution was successful.

Tested in the Field

Sure, theory is fine, but how does all this work when actually writing a Flex app? Well, I put that to the test just the other day. An app I’m working needed a significant enhancement and change. After changing the database model, I was able to crank out the business logic, and three views in Flex in which users could create new items, deactivate/activate them, and a few other doo-dads in just under 40 minutes.

Conclusion

Don’t be afraid to enhance a framework or code architecture with your own ideas. Trust yourself and your ideas because you’re smart, too.