This example uses the Contact Manager, a (very) simple flex application, that I talked about in Part 1 "Contact Manager Part 1 - Remoting Example".   I took that application and modified it to use the Cairngorm framework - "Microarchitecture is a lightweight yet prescriptive framework for rich Internet application (RIA) development". 

Cairngorm was developed by the folks at Iteration two (now part of Adobe Consulting) and is pretty easy to use.  There are some drawbacks (some of which have been solved by UniversalMinds Cairngorm Extensions) and I recommend anyone thinking of using Cairngorm to read a post by Steven Webster (Now on Adobe Feeds), also read this (its out of date somewhat, but the concept is still in tact), furthermore check out the Roundtable discussion on Coldfusion weekly, which provides some other insights to Cairngorm and talks about other Flex frameworks.  Normally you wouldn't use Cairngorm for something so simple as the Contact Manager, it simply isn't needed, but for a large application Cairngorm can be very beneficial and worth the extra code.

Ok, so in Cairngorm you basically have the following design patterns in use (forgive me if I miss one, going on memory):

• MVC (model view and controller)
• Singleton Pattern
• Command Pattern
• Delegate Pattern (something they cooked up for Cairngorm)

Cairngorm is made up of these main sections (a good overview can be found here):

• ModelLocator
• Controller
• The applications views (mxml components)
• CairngormEventDispatcher, CairngormEvent
• Events
• Command
• Delegate
• ServiceLocator

ModelLocator/Controller/Events

Inside the MVC part of Cairngorm is where you will find the ModelLocator, which holds the majority of the data in your Cairngorm driven Flex Application.  So for the Contact Manager I created public variables for my ContactVO and my View settings into my model.  One other thing to mention is that the Model part of Cairngorm uses the singleton pattern, which if programmed correctly insures only one instance of the model locator exist (see the contact manager code for an example of how to program this correctly).

Next we have the View, well this is really handled by Flex and all the great components we get out of the box.  This is your view, the mxml code that makes up your UI.  So I didnt make any view changes to the Contact Manager. Now usually you wont have the model and view connected at all.  In the Contact Manager example I actually only tie the main application file to the model and it passes the model through the rest of the components via bindings.  So none of those other components have a tie to the model. Only the main view does.  I believe Steven talks about this in his articles. 

The events is how we notify the controller that something has occured in our View.  We might want to modify our model, contact a web service, get more data (lazy load), etc... there are really multiple reasons a view dispatches an event.

Finally we have the controller. This is the part of Cairngorm that listens for events that the CairngormEventDispatcher has sent out.  When it sees an event it recognizes the controller calls the appropriate command to do some type of work.

Command/Delegate/ServiceLocator

Once the controller relays the event to the appropriate command.  Which is decoupling the work from the initiator.  In this case the View.  The command is responsible for making sure the task gets completed.  It doesnt necessarily have to do the work itself.  It can have a working class do it, or pass it on to a delegate to call some type of service....  If we wanted to code the work in the command we could... but why?  Why not keep the decoupling strategy going? 

In the Contact Manager example we pass the work onto the delegate and command awaits a response.  In this case our working class is the coldfusion code, again I didnt make any changes to this portion.  I used the Coldfusion Wizard to create this code and made some minor tweaks. I could of easily used the Illidium PU-36 Generator as well and had the same result, except with better code (in my opinion).   Once the delegate sends the response back the command finishes up the job, in this case our contact manager's model gets updated with new data.

I already talked about the Delegate a little bit, but basically this is where we create methods to call particular services within our ServiceLocator.  Once the delegate gets a response from the service it transmits that response back to the command.   If its a good response, the command runs the result method.  If its a fault the command runs the fault method.  Simple huh?

The ServiceLocator holds all of the services, which could be remoting calls, HTTP calls, or it could be a DataService call. In this example we are only using Remoting calls.

Thats Cairngorm in a nutshell!  I am not going to copy and paste any code examples from the Contact Manager in this post.  All of the code is available for download here and you can check out the application in action here.  I also have a AIR example that just uses the normal Contact Manager code, except its not talking to a service.  It uses the SQL-Lite Database instead and runs strictly on the desktop.  I hope to find time to post about the details soon.

I will be converting the Contact Manager over to Mate in the near future so I can see how that framework "works", I may even compare it to Cairngorm ;)