网上一段简短扼要的cairngorm介绍：
Cairngorm的组成：
1. Model Locator：保存应用的ValueObject（数据）和共享变量，与HttpSession类似，只不过是保存在客户端而不是在服务器端而已
2. View：一个或者多个Flex组件（按钮、Panel、下拉框等等）组合在成一个被命名的单元。绑定Model Locator中的数据，根据用户动作（点击、滚动、拖放）产生自定义的Cairngorm事件。
3. Front Controller：接收Cairngorm事件，并映射到对应的Cairngorm命令。
4. Command：处理业务逻辑，调用Cairngorm的代理或者其他命令，更新Model Locator中的Value Object和变量值。
5. Delegate：在命令中创建，初始化一个远程调用（Http, WebService等等），并将返回结果传递给Command。
6. Service：定义远程调用连接远程的数据存储。
Cairngorm的工作方式：
1. 客户端界面由各个View组成，View通过绑定Model Locator的成员来显示数据。View根据用户操作生成事件。这些事件由Front Controller广播并接收，然后映射到相应的命令。命令包含业务逻辑、创建代理来完成操作，处理代理返回的结果，并更新Model Locator的数据。因为View是与Model Locator中的数据绑定的，因此Model Locator中数据更新后，View自动反应出数据的变化。由代理调用服务并返回处理结果不是必须的，但是这是推荐做法。
官方说明：
Cairngorm是Adobe Labs上的Flex MVC框架
Cairngorm文档很少，其Wiki上有核心开发人员
Steven Webster写了6篇文章来介绍
Cairngorm:
Part I - Introducing Cairngorm
Part II - Keeping State on the Client
Part III - Architecting the View
Part IV - Feature-driven Development
Part V - Server-side Integration
Part VI - Rapid and Consistent Development with Cairngorm and Flex
Steven WEbster是Adobe RIA的practice director。
第一部分、介绍
Cairngorm:
介绍
这6篇文章的系列展示了一个叫
Cairngorm的面向Flex开发人员的开源框架。在这个系列里我解释了
Cairngorm幕后的主要思想和
Adobe给出的设计挑战。
Cairngorm是一个合适的开发架构。
这个系列使用
Cairngorm Store示例程序来解释当基于
Cairngorm开发时Adobe Consulting关于scoping、estimating和delivering
富Internet应用(RIA)的思考。我也解释了
Cairngorm的多种概念并深入
Cairngorm Store的实现。
最后，我通过以
Cairngorm开发人员的角度添加一个新特性到
Cairngorm Store程序来示范基于
Cairngorm微架构发布RIA的主要好处。通过这一步，你可以自己看到
Cairngorm的好处。
Cairngorm当然不是构建Rich Internet Application的唯一方式。但是，Adobe Consulting在已有的Flex程序开发经验的基础上曾
使用本系列文章里的信息来帮助大量客户和合伙人成功发布大规模Flex RIA。
这个系列从理解
Cairngorm的动机和概念到基于
Cairngorm架构你自己的程序完整的介绍了
Cairngorm。
第一部分提供了理解
Cairngorm架构的上下文和背景，而不是从一开始就一头扎进代码里。我讨论了框架，并澄清了程序框架和架构
框架之间的区别。然后我介绍了设计模式和微架构概念。最后，我给出
Cairngorm出现的背景:它的历史和roadmap。
在第二至六部分，你将在客户端和一个J2EE服务器端使用Flex和
Cairngorm开发一个零售商业程序。
澄清框架的定义
在软件开发里，框架这个术语是承受最多和最滥用的术语。当开发人员写了大量代码并认为足够重要来在其他项目中使用，他们趋向
于给代码赋予这个术语。这样就有了许多类型的框架:持久框架、事务框架、日志框架、面向方面框架、动画框架、单元测试框架等等
在深入讨论
Cairngorm框架之前，解释Adobe Consulting团队与客户和合伙人分享的关于框架认识的区别很重要 -- 特别是程序框架和架构框架间的区别。
程序框架
Flex是程序框架的一个典型的例子。即将发布的Flex 2.0事实上在架构上区别于程序框架 -- 通常在Adobe里称为"app model"。Flex框架2.0提供丰富的类库来提供高粒度功能性供开发人员创建自定义的代码。例如，Flex 2.0集合API提供开发人员用来创建受管的数据集合的底层功能性。开发人员组合这些集合为他们的特殊程序的高级对象。而且，程序框架如Flex也暴露了程序级的服务，如history管理、layout管理、cursor管理、exception handling、i18n、logging等等。
当框架提供高粒度类库来给开发人员提供高级别灵活性，或者当框架提供对多开发人员的项目有用的程序级服务时，我们仍可以称其为"程序框架"。
另一个程序框架的例子是Adobe Consulting使用的非常成功的
FAST框架。FAST框架提供了程序服务如logging、tracing和继承了Flex1.x框架自己的RPC data services的value-add类库，这在John Bennett的文章里也有所解释:
Faster Development with the Flex Application Starter Toolkit(FAST)
架构框架
架构框架是完全不同的野兽。架构框架除了提供给程序可以悬挂的基础组织 -- 提供骨架和内部结构来负载肌肉外不提供任何额外的服务给开发人员
换句话说，架构框架提供你的程序的技术架构通常的入口点。
使用设计模式
不关注软件工程里重大的改进 -- 设计模式的话，很难谈论技术架构。
"there is nothing new under the sun"这句话在软件工程原则里是再正确不过了。开发人员发现他们在程序开发中经常遇到不变的工程问题。而他们的解决方案也和所遇到的问题一样重复不变。不管这些重复出现在哪里，你可以将这些解决方案视为"模式"。
设计模式的诱惑
现在有一个警告:当软件工程师第一次遇到设计模式时，对工程问题解决方案的分类的意识可能非常强大。通常开发人员发现问题的子集并希望寻找其他可以利用的设计模式。尽管如此，"when all you have is a hammer, everything looks like a nail"这句老谚语在这里是适用的。你经常会在程序里发现"模式过度"，开发人员抛弃了类以及协作的责任，而是把任何东西都扔到Factory、Flyweight、Observer或Decorator里。
但是，合理的使用设计模式会成为开发人员的工具箱里一个强大的工具。设计模式不仅仅提供问题常见的解决方案，而且开发人员在程序中使用设计模式的方式也指示了实现的目的。例如，不管何时你在代码中使用Singleton时，你理解这是一个应该只有一个实例的类。类似的，无论何时你遇到一个Factory时，你会意识到工厂类可以产生一些不同的对象。
微架构作为设计模式的组合
...
Cairngorm的历史
iteration::two是我和Alistair McLeod创立的软件咨询公司，我们意识到要面对的许多在J2EE程序开发里成功解决的设计挑战在RIA世界里仍然存在。我们回到Flash、Flash Remoting和J2EE的RIA开发历史。
浏览Sun Microsystems提倡的设计模式
Core J2EE Pattern Catalog，我们首先在Reality J2EE: Architecting for
Macromedia Flash MX(Pearson Education, 2003)这本书里展示了Flash中这些模式的应用。随着Flash MX 2004的发布，我们在
Macromedia Flash MX 2004 ActionScript2.0 Dictionary(Macromedia Press, 2003)一书的"ActionScript 2.0 Design Patterns
for RIA Development"一章中也展示了这些模式。
由于RIA技术平台从Flash作为设计中心到Flex编程越来越成熟，使用这些模式的动机也出现了。但是，Flex编程模型给我们更优雅的方式来实现这些模式。而且，一些我们认为对Flash RIA开发人员非常有用的模式(例如|ViewHelper模式)在Flex RIA世界变得不再有用，我们也创建了一些自己的新的Flex特有的模式，例如ModelLocator模式。
在
MAX 2004中我们宣布了我们发布基于Flex的开源
Cairngorm框架的决定，这在社区中得到广泛影响。
Cairngorm教会你什么
Cairngorm是一个宣布了3个重要领域的微架构:
1, 在客户端处理用户动作
2, 封装业务逻辑和服务端交互
3, 在客户端管理状态并展示该状态到用户界面
Cairngorm提供一个微架构(一些设计模式的集合)，目标是解决上述重复出现的3个设计挑战。
当你阅读本系列文章时，你将学习如下内容:
1, Front Controller和Command模式怎样实现"Service to Worker"微架构来监听和响应用户请求
2, Business Delegate和Service Locator模式怎样工作来让你重用业务逻辑并封装它来在客户端和服务端开发团队之间建立
一个清晰的契约并且与服务端实现无关，如Web Services，EJB，ColdFusion组件甚至HTTP上使用XML的RESTful 架构。
3, J2EE里的Value Object模式怎样与ModelLocator模式协作来作为一个优雅的策略使用丰富用户体验维护有状态客户端
Cairngorm的当前状态