Cairngorm 框架

Cairngorm是已知的最为古老与最好的Flex 框架。它实际上是一个微架构——它提供了一系列已经被证明可以很好的互相协作的设计模式的集合。Cairngorm采用累来自Java开发世界的笨重并且把焦点集中到了三个关键区域：处理用户行为，包装服务端交互与业务逻辑，并且管理客户端状态以及在用户界面（UI）上体现客户端状态。

在Cairngorm构建一个项目包含了拆散你的应用到若干个包中并且扩展Cairngorm的类。如下是一个Cairngorm 项目 主要包含的部分和类。

ModelLocator —— 作为数据存贮角色的单件——反映程序的状态。单件类的性质抱枕了程序中所有的组件都访问相同的数据。
ServeiceLocator 是另外一个单件，它作为集中存贮例如HTTPService的服务的角色存在。同样，因为该类是一个单件，所有程序中的组件都会访问相同的服务。
业务逻辑被包装到了实现了命令模式的Command类中。这些类描述了程序响应用户事件的逻辑。
事件会被FrontController 类处理，它会针对事件来执行相应的command类。每个程序可以回应的用户事件都必须被注册到它所附和的command类。
Delegate 类会被用来做远端服务访问与反馈的代理。



优点
Cairngorm是Flex社区中众所周知的，并且是一个Adobe 开源网站上的项目，有良好的支持并且一个活跃的开发者社区继续为它工作。此外，它借用了来自Java开发世界的已被证明的策略。最后，它非常适合团队开发，因为它提供了一个高级的结构化的一套方法来允许分发任务进行创建应用。

缺点
或许对Cairngrom做出的最多的批评就是它需要你去写非常多的类。在Cairngorm中，每个事件映射到一个Command；因此，你不得不为每个在你的应用中可以被触发的事件写一个对应的command类。另外，你必须要写其他的command必须用到的其他类，例如delegate。这会快速的增加一个小型应用的类的数量到一个巨大的数字。

第二，因为Cairngorm 实现了它自己的处理事件的方法，这个会把内建的Flex 事件模型变得错综复杂。它也有其他一些限制。因为每个事件都必须要有它自己的command类，你就被限制只能为每个事件提供一个响应器（responder）.并且，Cairngorm事件并不会冒泡，所以如果你想要通知其他更高一级的容器，就只能自己来处理了。

第三条普遍的批评就是框架依赖于全局单例，让想要模块化和单元测试变的困难。虽然你可以从数个单例中破坏这个框架模型让这些处理简单些，但是额外的工作需求会复杂化流程。

资源
Cairngorm developer documentation
Developing Flex RIAs with Cairngorm microarchitecture – Part 1: Introducing Cairngorm (Steven Webster and Leon Tanner, August 2008)
Example Cairngorm project