Flex – Cairngorm Architecture Overview

Cairngorm is the lightweight micro-architecture for Rich Internet Applications built in Flex or AIR. A collaboration of recognized design patterns, Cairngorm exemplifies and encourages best-practices for RIA development advocated by Adobe Consulting, encourages best-practice leverage of the underlying Flex framework, while making it easier for medium to large teams of software engineers deliver medium to large scale, mission-critical Rich Internet Applications.

Cairngorm Architectural Framework

Cairngorm follows the principle of separating the view and business logic which is known as the Model-View-Controller pattern (MVC). The following list shows the different elements that form the framework.

1. View: Contains UI controls for user interaction and displays the state of the models data. Views dispatch events handled by the controller.

2. Model Locator: It acts as a centralized repository for all data needed in the application. It manages the view an is declared as [Bindable] to use all variables for data binding in the view. It must be implemented as a singleton which implements the Cairngorm IModelLocator. All data managed in the model should only be updated through a command or a responder object.

3. Value Object (VO): A value object is a class that only has properties to store values. It contains no methods or logic and acts as a pure data container. Value objects must implement the Cairngorm ValueObject interface. If they should be mapped to a corresponding server-side class it must declare the [RemoteClass (alias=”)] metatag. By doing so, Flex automatically converts an server-side object returned through remoting or data service interaction to its corresponding ActionScript object.

4. Event: In Cairngorm everything should be mapped to an event. Whenever the user interacts with the view or an action occurs an event must be dispatched. Custom events extend the CairngormEvent class an have a special property to contain the data that comes with it.

5. Command: Commands actually do the majority of an applications work. They recieve the event and its data, execute the logic an can change the workflow state of the model and view. Each command must implement the Cairngorm ICommand interface and its execute function. The revcieved event is a generic CairngormEvent and must be casted to the appropriate custom event first. The complete frontend-logic of the RIA is encapsulated within the commands.

6. Front Controller: It extends the Cairngorm FrontController class and maps the dispatched events to its corresponding commands. Therefore it has two methods: the constructor and an initialize method which will map an event to an command via the addCommand method. The controller is instantiated directly in the main.mxml via a component tag. You simply need to add the directory your class is in as an XML Namespace and then include the tag in the file.

7. Service Locator: Implemented as a singleton, it contains references to all services an application will use. Like the Front Controller, it is placed within the main.mxml via a tag. Possible services to be used are RemoteObjects, HTTPServices, WebServices or custom services.

8. Business Delegate: Business Delegates form an abstraction layer between the server-side services and the main frontend application. The locate the required service in the Service Locator, call the given method on it and route the response back to a responder object. Unlike the other elemente in the Cairngorm architecture, it does not extend a class or implement an interface, but it need to follow some guidelines: it must have at least two properties, one named reference to the ServiceLocator and one reference to a responder, both set in the constructor. And it must have implemented one method for each server-side method to be called. The delegate is created within a command object. It should only pass strongly typed value objects to a responder. If it does not recieve an appropriate object, it must create one before passing it.

9. Responder: Responders implement the mx.rpc.IResponder interface. A responder recieves the result of a service call and implements frontend-logic like a command. It directly may set values of the model and should only deal with strongly typed value objects.

10. Service: The Service is formed by an application tier, build with some server-side technology like J2EE or PHP. It Accepts the service requests from the RIA and responds back data. With a remoting technology like BlazeDS it is even possible to pass back value objects witch are transformed to their corresponding ActionScript objects in the application, so it can interact with them as if they are created by script.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s