Cairngorm is a Flex framework that defines a 9-point data encapsulation and transmission system. Cairngorm is the path that starts with the view dispatching user gesture events, and ends at the central data model, which triggers changes to view bindings.
Cairngorm is mostly about structuring a specific path in which data is processed when it is communicated and stored within the application.
These 9 points are:
Data originator. Not specifically a part of the Cairngorm architecture, the first point to consider is where the data is coming from. For example, the data can be coming from a form on the screen with a textbox. Most of the time, there is a "user gesture" involved in creating the data.
Value Objects. A value object is the data that we value; it is the whole purpose of starting the Cairngorm process. For example, the value object can contain a set of all the user input data in all the textboxes on a form.
User Interface Events. An event is created when the user takes a noteworthy action. For example, when the user clicks on the submit button, the form triggers a function that creates an Event, then encapsulates the value object into the event for transmission.
Event Dispatcher. Once an event is triggered, the dispatcher broadcasts the event so that it can be picked up by the Front Controller.
Front Controller (singleton). This is basically the main switchboard operator, who listens to all dispatched calls. It is trained to know which command(s) to create and invoke based on what event is being triggered.
Command. A command object is stateless, and instantiated only when needed. It exists to take action on a specific event. Each command may be designed to deal with one or more events. A command may update the central data model based on information from the event, and/or based on information obtained by a command delegate.
Command delegate. A command delegate is created by and deputized by the command to perform tasks. Usually, the task is related to handling communications with external data sources. It is created for the purpose of working with the service locater, and for giving the proper instructions to the service. When data comes back from the service, the command delegate should parse the data and send data up to the command object in a format that fits the needs of the command.
Service Locator (singleton). When a command delegate needs to communicate information with an external application or server, it looks for the service it needs in the Service Locator. A service locater basically contains instances of all the server communicator devices
Service. The service exists to communicate with an external data source. There is one instance of a service for each data source that the application communicates with. A service may communicate with any external platform that the application needs to exchange data with. It may be a web server, or another application running on the same desktop if Adobe AIR is involved. The job of the service is to communicate in raw format the information being provided by the server. It should do no parsing, or low-level parsing only.