Cairngorm Microarchitecture

1. Cairngorm Microarchitecture

2. Pronunciation Cairngorm (kârn gôrm) • n. yellowish-brown variety of quartz, especially found in Scottish Cairngorm mountain.

3. What is it? • Collection of classes/interfaces against which we can compile • Elegant collaboration and partitioning of design responsibilities • "microarchitecture" - Provide the skeleton or internal structure of moving parts, around which the flesh and muscle particular to a business domain can be layered • A standard way of building a Flex app.

4. Why use it? • Multiple developers working on the project, and run the risk of them all solving the same problem in multiple different ways • Unified approach to problems • Inject complex functionality in a well understood manner • Promote, enable and encourage reuse (business objects, business services, etc.)

5. The Pieces of Cairngorm • Model Locator: Stores all of your application’s Value Objects (data) and shared variables, in one place. Similar to an HTTP Session object, except that its stored client side in the Flex interface instead of server side within a middle tier application server. • View: One or more Flex components (button, panel, combo box, Tile, etc) bundled together as a named unit, bound to data in the Model Locator, and generating custom Cairngorm Events based on user interaction (clicks, rollovers, dragndrop.) • Front Controller: Receives Cairngorm Events and maps them to Cairngorm Commands. • Command: Handles business logic, calls Cairngorm Delegates and/or other Commands, and updates the Value Objects and variables stored in the Model Locator • Delegate: Created by a Command, they instantiate remote procedure calls (HTTP, Web Services, etc) and hand the results back to that Command. • Service: Defines the remote procedure calls (HTTP, Web Services, etc) to connect to remote data stores.

6. Cairngorm 2 Microarchitecture

7. Model • All client “state” data • Anything retrieved from server • Implements ModelLocator Cairngorm interface • The model locator in an application is a singleton that the application uses to store the client side model. • Summary: Model is a Singleton containing data.

8. View • User Interface • .mxml files w/controls (text fields, combobox, datagrid, etc.) • All data is pulled from model via a binding

9. Controller • Allows communication between tiers of application via • Events • extend class com.adobe.cairngorm.control.CairngormEvent • Commands • implement interfaces com.adobe.cairngorm.commands.ICommand com.adobe.cairngorm.business.IResponder (optional) • Tie Events and Commands together in Controller class • Conduit between user events and model changes

10. Events • Events classes usually just a • Collection of properties • Constructor with params to populate those properties • Used to pass data between layers of an application

11. Event - example package com.echoeleven.controller.event { import com.adobe.cairngorm.control.CairngormEvent; import com.echoeleven.controller.ApplicationController; public class LoginEvent extends CairngormEvent { public varusername:String; public varpassword:String; public function LoginEvent(username:String, password:String) { super(ApplicationController.EVENT_LOGIN); this.username = username; this.password = password; } } }

12. Command • “Service to Worker” command pattern • Must implement the Cairngorm Command interface • If receiving data from server (e.g. RemoteObject), should also implement Responder Interface • Command class must implement execute() method • execute() usually takes an event argument as a parameter

13. Command - example package com.echoeleven.controller.command { import com.echoeleven.model.ApplicationModel; import com.echoeleven.controller.event.LoginDataChangeEvent; public class LoginDataChangeCommand implements Command { public function execute(eventParam:CairngormEvent):void { varevent:LoginDataChangeEvent = eventParam as LoginDataChangeEvent; varappData:ApplicationModel = ApplicationModel.getInstance(); appData.username = event.username; appData.password = event.password; } } }

14. Controller • Tie Event and Command classes together in Controller class constructor addCommand( ApplicationController.EVENT_LOGIN, LoginCommand ); • Controller listens for event • When event is dispatched, command’s execute() method called (by controller) • Conduit between user events and model changes

15. Controller – Big Picture • View event triggered (e.g. click event) • Caught by private method in view (mxml file) • View method creates instance of event (extending CairngormEvent) • View method dispatches that event via CairngormEventDispatcher • Controller catches CairngormEvent and executes associated Cairngorm Command privatefunctionbtnClick( event:Event ):void { varevt:LoginEvent = newLoginEvent(userName.text, password.text); CairngormEventDispatcher.getInstance().dispatchEvent( evt ); }

16. Example Flow • Create LoginDataChangeEvent class • Create LoginDataChangeCommand class • Connect Event to Command in controller • Catch the TextField.change event, and call local function dataChange() • Create instance of LoginDataChangeEvent and dispatch it • LoginDataChangeCommand.execute() automatically called • execute() method modifies Model • Change to model reflected in View through binding

17. Service Locator • Singleton • Abstracts data communication layer • Defines which protocol (http, SOAP, AMF, etc.) and which endpoint params (which service, which channel, etc.)

18. Business Delegate • Who should handle the results of a server operation? • Avoids attaching result/error routines to data services (e.g. RemoteObject) • Allows Command to call remote object method, and handle the result and fault methods • Multiple instances may exist

19. Business Delegate • The Business Delegate typically fulfills its role in collaboration with the Service Locator; it uses the Service Locator to locate and look up remote services, such as web services, remote Java objects, or HTTP services. Once located, the Business Delegate invokes these services on behalf of the class that has delegated responsibility to it for business logic invocation.

20. References • Cairngorm Docs • Borrowed contents from Scott Talsma’s slide