本文和大家重点讨论一下Flex框架中Cairngorm和Mate的优缺点，Cairngorm是一个广为人知的老牌Flex框架，而Mate是一个基于标签的，事件驱动的框架。它们有什么不同点或者相似之处吗请看下文详细介绍。
如何选择一个Flex框架
Cairngorm
Cairngorm是一个广为人知的老牌Flex框架。它是一个微型架构——由一些设计模式组成用来降低团队协作的困难。
Cairngorm从Java的世界带来了很多开发理念，并且把重点放在三个关键区域：处理用户动作，封装服务端的交互和业务逻辑，管理客户端的状态和界面呈现。
使用Cairngorm来构建一个项目，需要将应用代码分离到不同的包并且继承Cairngorm的类。以下是Cairngorm项目中一些主要的部分和类。
ModelLocator是一个储存数据的单例，数据表示程序的状态。单例类的性质保证了程序中的所有组件取得的是相同的数据。
ServiceLocator是另一个单例，它集中管理所有服务如HTTPServices。同样，由于是单例，程序中的所有组件取得的是相同的服务。
业务逻辑被封装在command类中。command实现了命令模式，它们表示相应用户事件的逻辑。
事件被类FrontController处理，FrontController会把事件映射到相应的Command。
Delegate类作为代理来对远端服务进行请求和响应。
优点
Cairngorm在Flex社区广为人知，作为Adobe开源项目的一员，拥有活跃的社区和开发者的支持。
其次，该框架吸取了Java开发中许多宝贵的经验，并成功得用于大型项目的开发中。
并且，Cairngorm适用于团队开发，因为它提供了结构化的开发方法来创建应用，利于分布式的开发。
缺点
需要写大量的类应该是Cairngorm最多的负面评论了。在Cairngorm中，每一个event对应一个command；因此，需要对程序触发的每一个事件来写一个command类。而且，还要为command写一些其他的类，例如delegates。即使是一个中型的应用也会导致大量的类产生。
其次,Cairngorm实现了自己的一套事件处理的方法。这增加了Flex内置事件模型的复杂度，而且它还有限制。由于每个事件都有自己的的command，事件的响应者被限制成1个。加之Cairngorm的事件不具冒泡特性，如果要发送数据到容器的其它层次则需要自己来实现。
第三个常见的批评是Cairngorm依赖全局的单例，这让模块和单元测试变得困难。尽管可以打破单例中的模型简化测试，但是会增加额外的过程。
资源
Cairngormdeveloperdocumentation
DevelopingFlexRIAswithCairngormmicroarchitecture–Part1:IntroducingCairngorm(StevenWebsterandLeonTanner,August2008)
ExampleCairngormproject
Mate
Mate是一个基于标签的，事件驱动的Flex框架。基于标签意味着它可以完全实现在MXML中。该框架的目的是让事件响应者的声明变得简便。
在项目中使用Mate只需要处理两个方面：使用1个或者多个事件，有一个成为”eventmap“的MXML文件——被包含在主程序中的一个MXML文件。它定义了需要监听的事件以及如何被处理。必须有1个eventmap，而且允许有多个。
Mate也实现了依赖注入（Dependencyinjection）的理念——有时被称为好莱坞原则,或“don’tcallus,we’llcallyou”。对象的创建时这样一种方式：数据被创建并且注入到对象中。也就是说，对象不会喊着要数据（”don’tcallus”），而是数据被传送给对象（”we’llcallyou”）。
优点
Mate使用依赖注入提升了松耦合性。因为组件不依赖全局的单例，能更自由地作为对立的部分。Mate不会阻止你使用Flex内建的事件机制，也不会像Cairngorm一样为每个事件都使用单独的响应。Mate的MXML标签文件简单易用，而且文档优秀，在官网上有大量的代码实例。
缺点
Mate使用MXML文件构建，要是作为一个ActionScript开发者，就需要调整自己的习惯。而且Mate没有为应用程序制定结构，这份工作留给了开发者。
因此，需要加强团队协作来保证代码的兼容性。还有一个问题与AdobeLiveCycleDataServicesES有关，要知道Mate暂时还不能处理LiveCycleDataServices提供的数据管理方面的功能。
翻译自：http://www.adobe.com/devnet/flex/articles/flex_framework_02.html