The first part about the Flex Cairngorm architecture covered all needed elements and basic patterns. This article while take a closer look on the interaction of those parts and introduce the concepts behind them. It will cover the basic event flow, server interaction and a typical Cairngorm application layout.

Service to Worker pattern

The Serivce to Worker pattern encompasses most of the logic for a Cairngorm-based application. It is a microarchitecture that combines an Front Controller, Commands, Events and a Dispatcher. The Controller registers to listen to all events broadcasted by the application. The Events themselves are mostly dispatched by user gestures within the view. When retrieving an Event, the Controller looks for the appropriate command for handling that event. It dipsatches the control to the Command. The way that these classes interact form the Cairngorm Event Flow.

Cairngorm Event Flow

One of the most important things to understand about Cairngorm is that everything should be mapped to an event. This sounds a littel bit drastic – and exceptions prove the rule – but it holds true in most situations. The following example illustrates a typical event flow.

1. View The user clicks a button within a view component.
2. Dispatch Event On click, the component dispatches the event bound to that action.
3. Front Controller The Controller recieves the event and executes the mapped Command.
4. Command Some business logic is executed by the Command.
5. Model The logic in detail alters the data stored in the Model.
6. View Since the view is bound to the model data, it will reflect the changes.

Server interaction

When your application requires some kind of server-interaction the Service to Worker pattern can easily be extended to fit those needs. By using the Service Locator, Business Delegates and Value Objects, you can seamlessly integrate an application tier to your applications flow. The flow itself can be divided into three phases:

1. In the Execution Phase, a Command, dispatched after an Event by the Front Controller, creates a Business Delegate, passes a responder and calls a method on it. The Delegate uses the Service Locator to get the required service and calls the specified method on it.
2. The Application Tier Processing Phase runs on a backend server. It executes business logic and works on Value Objects passed by the service. To enable communication between the tier and your Flex application, you might use a remoting and messaging technology like AMFPHP or Java based BlazeDS. Both use the AMF format which allows the use of native data types and complex object mapping between the client and the server.
3. In the Response Phase, the Delegate recieves the server result from the service. It passes the result to the Responder which changes the Model. Since the View is bound to the model, it will update itself automatically.

Separation of concerns

A common problem for Cairngorm developers is the right handling of Responder, Command and Delegate objects. You should keep the following responsibilities in mind:

• Responders – only deal with strongly-typed application objects. They may set values on the model.
• Commands – do not deal directly with server interaction. They may set values on the model.
• Delegates – should only pass strongly-typed application objects to the Responder. If it doesn’t receive appropriate objects, it must parse and convert the data into that format (by using a factory class for example).

By using this seperation, you can switch out the services by only changing your Delegate. The data passed from the service to the delegate can be any format. But the transfer from the Delegate to the Responder needs to be application data (Value Objects, model classes).

Application layout

A proper project organization is important for any project you are working on. Cairngorm defines a basic application layout which is organized in the following manner:

• A Main.mxml file is the main application file for the application.
• The project files are contained in a folder structure that uses “reverse-dns” format (e.g. de.flamelab.application.*).
• Within this structure there will be the following folders:
  • events/ – custom events for the application
  • control/ – FrontController for the application
  • commands/ – Commands called by the FrontController
  • model/ – ModelLocator and other model related classes
  • view/ – view components and related classes
  • business/ – ServiceLocator and Business Delegates
  • vo/ – value objects passed to and from the server