一、Cairngorm框架的工作流程：
1. 前端控制器（FrontController）监听用户行为
前端控制品是Cairngorm事件的唯一监听者，但其不并做任何操作，只是集中注册并管理事件（Event）与命今（Command）的映射关系。
2. 命令（Commands）执行所有用户操作
前端控制品（FrontController）监听到事件与命令有匹配时，便告诉命令（Commmands）调用execute()方法处理事件。
3. 服务器端业务逻辑委托给Business Delegate
当命令（Commands）执行时，它只是关心是否获取到数据，而并不关心获取到什么具体数据。因为经常需要从服务器端获取数据，此时命令（Commands）更喜欢把它委托给其它类去操作。所以需要处理服务器端业务逻辑的时候，你都可以委托给命令（Commands）可以调用的 Business Delegate类去处理。
4. Business Delegate在Service Locator中寻找RPC Services
Business Delegate给命令（Commands）和RPC Services提供一个无缝接口。Business Delegate通过查找和匹配 PRC Services的名称来调用services并返回结果给命令（Commands）。命令（Commands）要从Business Delegate获取返回结果数据必须通过IResponder接口(mx.rpc.IResponder)，只有这样Business Delegate才知道命命令（Commands）有onResult()和onFault()来处理返回的数据。
5. 把数据存储为Value Objecs
强烈推荐把数据存储为Value Objects。
6. 在Model Locator保存状态并且让Model通知View
Model Locator是一个保存应用程序全部状态和包含Value Objects的地方。当应用程序状态改变时，Moel Locator 通过Data Binding方式来通知View改变。
Cairngorm框架的工作流程存在如下主要问题：
二、Cairngorm框架的工作流程问题分析与解决办法
该工作流程在实践中的一个主要问题是Model Locator全局单例类，该设计将应用中的所有数据集中于Model Locator，有很多优点，也导致了众多问题出现，如：
1. 灵活性低：相当于一个新的GOD类，知道应用中所有信息。而复杂应用中的众多数据难以被一个GOD类包含。框架对Model Locator存在严重依赖，未来的变更将变得困难。
2. 问题测试困难：Model Locator对所有Commands公开，当出现数据问题时，难以检查问题原因。
3. 数据校验困难：View通过绑定刷新显示，难以对数据进行检查和校验，从而也不能更友好的进行用户提示。View不能直接得到数据，不方便对数据进行检查和其他处理。
FLEX与Cairngorm框架学习使用心得体会
在学习的过程中，有些事情只需要学习怎么做（know how）就行，有些事情必须知道为什么（know why）。这种有区分的学习方式是学习效率的重要保障。
一、 FLEX
1、 事件驱动
FLEX的事件驱动模型架构是基于Observer设计模式，以界面事件为中心的。事件以消息形式按照组件层级进行广播。组件如果订阅了该事件，组件的事件处理方法被触发。不同与BS的请求响应模式。
该事件体系分为：
a) 事件触发：可视化组件可以调用dispatchEvent方便的手工触发事件。当然也可以在界面上操作以触发事件。
b) 事件消息广播：事件触发后，触发组件为目标组件，以目标组件为基点向父组件层层广播，称为事件流。
c) 事件捕获与处理：注册了事件监听器的组件的事件处理方法被触发，开始执行事件处理。
d) 事件流控制：默认情况下事件层层广播，直到最高层级的Application为止。当然，也可以对事件进行如下控制：
i. 中断：使用stopPropagation()和stopImmediatePropagation()中断事件 流。中断主要用于事件处理完成情况下为避免父组件也接收到事件消息而出现不可预期的行为。（合理利用中断体现了开发人员对所开发软件的控制力。）
ii. 伪装：伪装并非标准技巧。修改事件中的信息，可以将事件进行伪装。主要用于改变控件的默认行为。
iii. 变异：原事件流继续，同时触发新事件开启新事件流，这为FLEX代码增加了无限的灵活性，也大大增加了理解难度。打开FLEX的源码，可以看见很多。
事件驱动模型架构是FLEX开发的中心，没有理解和掌握该模型架构，就不能妄谈FLEX开发。FLEX中大量使用事件，导致代码阅读和理解存在一定困难，所以要学习FLEX必须先花大功夫熟悉事件驱动模型。
2、 动态化与反射
动态化和反射是灵活的开发框架必不可少的部分。FLEX的编译机制也很有特点，只能编译Application能够访问（静态或者实例）到的类文件 才能够被编译进入SWF中。这种编译机制有效的减少了SWF文件的大小，但是也有个比较大的缺点，就是动态代码开发与运行成为问题。
如果要开发一个灵活的可以二次开发的开发框架，需要有效利用动态化。
a) 将二次开发的代码放入Application可访问路径。
b) 利用反射动态调用代码。
3、 方法参数-函数式编程
FLEX另一个特点是方法参数，这点与常用的面向对象语言JAVA有明显区别。有效使用方法参数将带来巨大的灵活性，比如使用自定义方法改变控件属性或行为、回调callback。
方法参数与常用的面向对象语言JAVA有明显区别，原面向对象编程的开发人员需加强理解。
4、 RPC异步调用
RPC异步调用其实也是事件驱动模型的一种应用。RPC调用是FLEX与远程服务器通讯的方式，是企业应用程序中必不可少的部分。
RPC异步调用类似于AJAX异步调用，与平时习惯的请求响应模式的同步调用有很大区别。需要开发人员转换思路加强理解。
二、 Cairngorm
Cairngorm是应用一系列设计模式和软件开发实践开发的FLEX企业应用微架构。其核心是基于FLEX的关键特征和企业应用的架构模式。
1、 事件机制
Cairngorm在FLEX的事件驱动模型基础上定义了一套新的事件驱动模型。FLEX本身的事件驱动模型可以认为大部分是基于可视化控件的，FLEX的事件驱动模型的事件流是从目标控件开始层层向上传递知道Application的。
Cairngorm的事件驱动模型的构建是在Application层级用FController构建全局的事件监听器。FController监 听到Cairngorm事件后调用对应的Command。Cairngorm事件驱动模型的特点是：直接在Application层级，没有多层传递。并 且一个事件对应一个Command一一对应。
Cairngorm的事件驱动模型适合于处理业务逻辑，也仅适合于处理业务逻辑。最好不要用Cairngorm事件来处理界面行为。
2、 动态化与反射
Cairngorm没有直接使用反射。但是遵循了FLEX编译器的规定，在Application中引用FController和Service以保证所有Cairngorm的相关代码均被FLEX编译到SWF中，便于在应用中调用。
3、 MVC与多层架构
Cairngorm框架的一个重要特点就是其MVC的多层架构设计，其中FController是其MVC模式的关键控制器。看到有网友介绍Cairngorm的文章对此框架的首要调整就是去掉FCotroller，这就相当于没有利用Cairngorm框架的最大优点。
Cairngorm框架对表现层（View）划分很清晰，View触发事件，FController作为控制器，提交到Command开始的业务逻辑层。
而业务逻辑层的划分就不是那么清晰了，因为业务逻辑层是跨FLEX和后台服务（如J2EE）的。有2种设计方式，第一种是可以大部分放在J2EE的 后台服务层，Command、Delegate、Service都只作为代理，这种更加类似与原BS多层架构的逻辑。另一种设计方式可以将业务逻辑全部放 在FLEX中，后台服务仅作为持久层，类似于CS双层架构的逻辑。当然也有2种设计方式的混合，部分放在FLEX中，部分放在后台服务中。业务逻辑层的设 计与分布是最考验架构设计师能力的部分。
4、 RPC异步调用
Cairngorm框架利用RPC异步调用与后台服务通讯。在此处，性能设计是一个关键点，可使用的设计模式包括Facade模式。此处是FLEX与后台服务的接口，接口处更考验设计功力。
三、 总结
个人认为，在对FLEX的学习过程中，思维模式的转变很重要，尤其是要重视事件驱动模型、方法参数这两个与J2EE等面向对象开发思想的转变。这两点一定要做到为什么（know why）。
在对Cairngorm框架的学习、使用乃至调整的过程中，事件机制和MVC模式必须做到为什么（know why），而动态化与反射和RPC异步调用仅需做到怎么做（know how）就可以了。