What is Cairngorm?

Adobe Consulting Group has defined an architectural framework for Flex application, named "Cairngorm". The framework has borrowed quite a bit of design patterns from GOF and J2EE. Its goal is to help us to layout the groundwork for complicated RIA. It is interesting to see how those patterns work together in a seamless way. The framework not only cleans up our code, but it also decouples our components. The result is very neat and elegant!

Lets go through some interesting points for this microarchitecture. I assume you already read this excellent 6 parts articles from Steven Webster.

Encapsulate your Flex component and make it no dependency to the Cairngorm framework to promote high reusability

• To do a better encapsulation - input (VO) and output (event) are non-Cairngorm object.
• Component internally use VO to bind to its controls and external link VO from ModelLocator to it. So, whenever the VO in ModelLocator be changed by Command, the components’ controls that link to it will be updated.
• User gesture is first captured by the component via event listener and then re-dispatched as custom event and bubbled up. Have the View that uses the component to capture the custom event and re-dispatch again as one type of CairngormEvent with VO loaded. In Cairngorm 2.2, you simple can call the "dispatch()" method from the CairngormEvent. Then, the FrontController can take care the rest. The CairngormEvent dispatched should be non-bubbled and cancellable.

View is the place for layout the controls and interact with Cairgnorm objects (normally it is non-reusable)

• View can set up control with VO from ModelLocator and capture custom event from control and re-dispatch it as a type of CairngormEvent.
• View contains state definition that is explicitly binding to the ModelLocator where it contains what state the View should be. The code below indicates that when the search_state is changed, the searchState() method will be invoked and alter the state of the View.

<mx:Binding source="{ModelLocator.getInstance().search_state}" destination="searchState" />

Command should be the one that changes the model

• FrontController is a registry that associates Event with Command. This mapping can be M:1.
• Consider ModelLocator is a mediator for Views to interact one another via changing the model.
• Delegate may intercept the response via registered its result and fault handler. The goal is to hide the detail from remote call. Therefore, it is good practice to convert XML to VO (via Factory) before invoking Command’s result and fault handler.

var token:AsyncToken = service.send(params); var responder:mx.rpc.Responder = new mx.rpc.Responder(searchBooks_onResult, searchBooks_onFault); token.addResponder(responder);

How to unit test Cairgnorm-enabled project

• VO, Service, FrontController, Event and ModelLocator are simple classes that are not subject to test.
• Command can be tested with Mock Delegate
• Model can be tested if it contains logic
• Factory can be tested if it contains parsing logic.
• Delegate can be tested with Mock Service (but a bit tricky as how to write a mock service)
• Control can be tested via addListener for the custom event thrown.

References

• http://www.adobe.com/devnet/flex/articles/cairngorm_pt6_print.html (very good 6 parts articles)
• http://jharbs.com/blog/?p=96
• http://blog.thinkingdigital.org/?p=3 (Eclipse plugin for Cairngorm)
• http://www.ericfeminella.com/blog/cairngen/ (code generation for cairngorm)
• http://www.zeuslabs.us/ (Yahoo engineer for Cairngorm)
• Amazon example from Jesse Warden
• http://www.ariaware.com/products/arp/manual.php (ARP - another framework for RIA)

Update

Recently, I have heard that PureMVC provides a clean framework than cairngorm as cairgnorm uses a lot of singleton framework class. I haven’t got a chance to look into it. Be sure will keep you update if I find it interesting.