1.Front Controller Listens for User Gestures
前端的控件监听用户的行为。注意它只是监听，并不会做任何反应。 2.Commands Do All the Work
控件监听以后调用Commands来做相应的事情，Command做了所有工作。 3.Delegate Server-Side Business Logic to Business Delegates
把服务器端的业务逻辑委托到 Bussiness Delegates中。因为很多时候command需要获得服务器端数据，所以这样一来它可以直接调用Bussiness Delegates而不用关注如何连接数据的细节，实现了信息隐藏。 4.Business Delegate Finds Services with the Service Locator
Command调用Business Delegate 后，Business Delegate 通过Service Locator来找到相应的RPC services，然后执行实现从服务器端取数据。 5.Transfer Data as Value Objects
把传输过来的数据存储为Value Objects。这点大家应该都很熟悉，比如想要查询一个公告，就必定创建一个公告类，来存储每一个公告的标题等信息。 6.Store State in the Model Locator and Let Model Notify View
在Model Locator 保存状态并且能使Model检测到View的变化。这样一来用户操作就能直接影响Model，比如添加物品到购物车，Model中的购物商品就会自动增 加。
前台控制器监听用户动作
用户处于这次会话的主导地位。你的RIA等待来自用户的一些提示。这些提示包括：点击按钮，拖放图标，双击行或是发送表单，这些都叫做“用户动 作”
Cairngorm 将这些用户动作翻译成Cairngorm事件。无论是点击，按下，拖曳，放下，提交的事件都代表用户的需求，你使用事件广播器广播事 件。事件广播器是Cairngorm会话的开始。
前台控制器模块是Cairngorm事件的唯一监听者。聚集不同事件句柄，前台控制器确保满足用户的需求。
无论如何，前台控制器不做具体的工作。它只是一个管理者，不是一个工人。前台控制器 负责管理着一份名单“谁做什么？”，一份命令名单，命令对应着相应的事件。
命令做全部的工作
一旦前台控制器发现一个事件对应的命令，它将告诉命令去执行。前台控制器告诉任一或 每个命令去做什么以一种一致的方式：前台控制器调用命令中的execute()方 法，但命令会做它自己特殊的事。
将服务器端的业务逻辑委派给业务代理
很多情况下，命令需要服务器支持。在RIA中，许多业务逻辑执行在客户端。但是或多或少，你需要将不些业务逻辑移到服务器端执行。
命 令不关心一些事是如何完成的。它们只关心它完成了。命令更喜欢将服务器端的业务逻辑委派给其它类。这是好事，毕竟，一些命令要实现远程任务，它们都会需要 相同的服务。另外，对全部命令来说，事务逻辑还没有写在服务器端。可能命令只是简单调用虚构的业务代理类，服务器端结构中并不存在这样的类，但是业务代理 提供了一种接口，以备未来使用。
所以不论何时你有业务逻辑，将它放在业务代理类中，这样你的命令可以调用其中的方 法。
业务代理在服务定位器中寻找服务
业务代理为命令和在服务器端的服务间提供了一种完美的接口。这些服务可能是Java服务，ColdFusion组件，Web Services,或是简单的HTTP服务。业 务代理对待这些服务都一样，当命令提出时调用它们，当服务是可用时立即返回结果给命令。
无论如何，这些服务的具体实现(Java类名或是CFCs,无 论它们有名称或是没名称的服务，WSDL文件，或是HTTP服务的URLs)都装入一个服务库里，叫做服务定位器。
服务定位器是你的RIA需 要的全部服务的目录。因为只有业务代理有权调用服 务，只有业务代理使用服务定位器在调用这些服务前按名称定位服务(不 关心服务的实现),返回结果给命令类。
记住，任何一个命令类（负责响应服务调用，从业务代理中返回数据）都必须实现响应接 口。这样，业务代理知道命令有一个onResult()方法来 获取全部结果，一个onFault()方法来截获错误。
以Value Objects来 传输数据
数据在客户端和服务器端传输时会发生什么，在客户端又如何？Cairngorm强调你可以处理数据可以稍微自由些，将它装入Value Objects，Value Objects强调了数据在业务形式上是什么(它是规则)，而不是技术形式上是什么（包含字符和数字对象的数组）。
模型定位器中的存储状态和模型关联视图
最后，你的应用程序必须与用户交流。在Cairngorm中，模型定位器保存着全部应用程序状态。虽然我们不关心 用户的体验是如何用MXML和ActionScript实现的，但是我们强调在任何地方视图总是动态的， 视图使用数据绑定将数据绑定到模型定位器。
模型定位器只包含Value Objects.当你的命令类使用业务代理去调用服务器端的业务逻辑时，它实现了响应接口，在onResult()方法实现接收Value Objects或是Value Objects集合。
Cairngorm应用程序会话的最后部分引起的结果是命令更新了模型定位器中的用Value Objects表示的新状态。模型定位器使用数据绑定来通知视图，用户接口更新来显示新的数据，完成用户会话。
以上我冗长的描述是关于通过Cairngorm架构不同设计模块的控制流。任一或是每个在应用程序中的feature都按照相同的执行过程，用户动作生成事件，事件调用服务，数 据传回模型。
向Cairngorm应 用程序添加新的Feature
当你向Cairngorm应 用程序加入一个新的feature时，它的过程很简单：
1．注册一个事件和命令，用前台控制器使用addCommand()方法
2.实现一个新的命令如下：
a.实现execute()方 法
b.实现onResult()方 法从服务器中获取结果
i.用于更新模型定位器的任何结果
ii.模型定位器自动更新视图。
3.加入任何新的服务调用，在命令需要业务代理时。
4．如果这些服务调用需要新的服务时，把它们加入到服务定位器中。
另外，你需要创建Value Objects用于在命令与业务代理间，业务代理与服务器间传输，或者存储到模型定位器中。更特别的，你的ValueObjects可以在你开发应用程序前就存在，你可以不断重用它 们，当你向应用程序加入新的feature时。
是的，当你的应用程序不断扩大时，服务器端服务很快就禁闭了，应用程序开发速度更 快，如下：
1．注册一个事件和命令，用前台控制器使用addCommand()方法。
2．实现一个新的命令。
这真的就是全部的。
调试一个Cairngorm应 用程序
调试一个Cairngorm应 用程序按照相同的可见步骤。如果一个需求模块不能响应用户的动作，调试过程总是这样：
1．检查事件是否在前台控制器中注册过。
2．检查命令中的execute()方 法是否被控制器调用。
3．检查相应的代理方法是否被调用。
4．检查命令中的onResult()方 法是否被调用。
5．检查模型定位器中的模型是否更新。
用这五步骤，你可以很轻松地分离问题，并修复它。