介绍
最近，我进行了很多次的Adobe Flex
开发职位的面试（作为自由职业，这点需要澄清，如果我现在的老板碰巧阅读到该文的话）。几乎每一次的面试，Flex框架的问题最终都会被提出来（通常就是
Cairngorm）。我就会解释尽管我知道这些框架的存在，但是我从没有真正的去用它们。这个决定看起来对我来说足够理智，但是这些不能给面试带来深刻
的印象。我开始厌倦因为我的“对Flex框架缺乏经验”而失去项目，我展开了一项任务仅我所能的去学习它们。
非常巧，本地用户组的下一次聚会提到了Flex框架的话题，具体提到Cairngorm,
Mate以及PureMVC(你可以在这里看观看)。我时常在Flex
show播客上听到所有的这些框架，但是从来没有真正的意识到他们是如何运作的以及他们之间的不同，本文的目的就在于指出这些。
本文提供了当前最流行的Flex框架，你可以根据了解来选择最适合你的团队或者项目的需求的框架。本文覆盖了
Cairngorm、Mate、PureMVC以及Swiz 框架。我特意选择了这些框架是因为它们已经被Flex show
播客提及并且或者已经被类似360|Flex 的会议所提出。
要求
完成本教程, 您需要安装以下软件和文件:
Flex Builder 3
必备知识
读者需要知道什么是Adobe Flex。当然，如果读者对框架涉及的内容有基础的了解，对面向对象编程原理以及设计模式的基础了解的话，对于阅读本文那就更有帮助了。
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事件并不会冒泡，所以如果你想要通知其他更高一级的容器，就只能自己来处理了。
第三条普遍的批评就是框架依赖于全局单例，让想要模块化和单元测试变的困难。虽然你可以从数个单例中破坏这个框架模型让这些处理简单些，但是额外的工作需求会复杂化流程。
资源
Mate 框架
Mate 是一个基于标签的事件驱动型框架。基于标签意味着它可以完全使用MXML实现。事件驱动使框架的主要焦点放在更简单的来定义事件的回应。
使用Mate来创建项目只需要两个基础的必要条件：
你必须有一个或多个事件，以及你必须有一个成为“事件映射”的MXML文件——其实就是在主要的应用程序文件中包含了一个简单的MXML文件。它定义了你
想要监听的事件以及这些事件该如何被处理。你必须至少有这些文件中的一个，在需要的情况下也可以使用多个事件映射。
Mate也实现了依赖注入的思想 ——有时，适用于好莱坞原则，即
“不要给我打电话，我们会打电话给你们”.对象被这样构造出来：需要的数据会被供给或者注入到类中。也就是说，类不去呼叫外部获取数据（即“不要给我打电
话”），而是接受他们所需要的数据（即（“我们会打电话给你们”））
优点
Mate
通过它对依赖注入的使用实现松耦合。因为组件不用依赖全局单例，对场景来说他们是自由人。Mate不限制你使用Flex的内建事件模型，也不会像
cairngorm一样限制你每个事件都要一个单独的响应处理。Mate
的MXML文件以及标签直接并且便于使用，同时如果你卡住了，它提供了不错的文档并在网站上有大量的代码范例。
缺点
Mate只使用了MXML。所以，如果你是那种做每件事都喜欢使用ActionScript类的人，那么你就必须要调整你的正常习惯。因为Mate
不会为你的应用定义一个结构，它留给你来定义。从此以后，你将会不得不协调自己的团队来确保你的所有开发人员以一个相容的方式编码。最后，如果你碰巧需要
和 Adobe LiveCycle Data Services ES协作，那么请注意，Mate一般不会处理LiveCycle Data Sevices ES 提供的数据管理。
资源
PureMVC 框架
虽然Flex也可以使用PureMVC框架，但是它实际上并不是作为一个Flex框架而设计的。PureMVC的创建者希望PureMVC框架是与语言无关的。其实，如果你访问他的网站，你会发现在多种语言上的实现以及代码范例。
PureMVC 以模型—视图—控制器模式（MVC
模式）为中心，以把项目切分到模型，视图以及控制器层为目标。PureMVC中通过是Model，View以及Controller，这三个单件类体现了
这些层——而为了帮着这些层之间通讯使用了第四个单件类Façade ，同时他也作为中央存贮器的角色存在。
和Cairngorm很像，创建一个使用PureMVC框架的项目，需要分割你的项目到若干包中，然后通过继承框架的类来显现你的定制类。PureMVC 还加入了作为程序主入口点的Façade类。
优点
类似Cairngorm，PureMVC一个稳定的框架并且拥有一个庞大的活跃社区来支持它。因为它为应用需要如何被创建以及开发人员之间的标准化编码提供了一个意义明确的结构，所以它也非常适合团队开发。
缺点=
由于对单件的依赖，PureMVC
很容易就获得与Cairngorm相同的批评。它并不是一个专门针对Flex的框架，所以它并不会像Cairngorm般利用MXML的特点。和
Cairngorm一样，PureMVC对于事件处理拥有它自己的方法，并且它会使标准的Flex事件模型更难运作。PuremvC
是一个相当复杂的框架，相对更难快速学会。除非你的团队非常熟悉它，培训新的雇员会提高生产时间。
最后，还是和Cairngorm 一样，PureMVC框架需要创建很多类，这些创建工作会增加生产时间和项目的大小。
资源
Swiz框架
Swiz
是一个为简化事件处理与异步远端方法呼叫提供方法的控制反转（IoC）框架。Swiz框架主要的焦点放在以一种简单有效的方式提供一个可靠的MVC规范。
和Cairngorm以及PureMVC所不同的是，它直接回避了宏大的Java模式并且不会强调任何预定义的文件夹结构。
使用Swiz创建一个项目需要告诉Swiz框架关于你的应用的组件。在Swiz的核心，Swiz是一个集中的工厂模式。组件都会经由一个成为BeanLoader的工具类载入到这个工厂。当应用开始的时候，工厂处理这些组件的实例化。
与此同时，Swiz 通过Autowire这个自定义Metatag来提供依赖管理。Autowire标签是Swiz为你处理定义类之间依赖性的一个方法。
优点
Swiz是使用简单并且不用为你的项目强制定义结构。凭借它的Autowire
依赖注入系统，和Mate一样，既确保了组件之间的松耦合又为你管理了依赖性。同时，Swiz也和Mate一样，使用了内建的Flex事件处理机制，这一
点在使用内部单件实现了全局事件分发之类的重要方面是非常有帮助的。
缺点
然后，又是和Mate一样，Swiz并不为你的应用的结构定义许多，它留给你自己去做。所以，你将会不得不为你自己的团队协调来确保你的所有开发人员以兼容的方式编码。
第二，因为它使用了自定义的metatag，所以项目需要一些附加的设置——例如，设置一些额外的编译参数。或者这些步骤不困难，但是其他框架不需要，而Swiz却需要。文档指明了Flex 2用户，所以他在flex2之后的版本将不再是一个问题。
资源
做出你的选择
虽然还不是很彻底，但是这里提供的信息配合资源，应该能够为你对每个框架的方法，优点以及缺点提供了一个基本的了解。你会怎么从这些框架中选择一个超过其他框架的框架呢？
也许第一个问题是，我是否需要一个框架？Flex 与MXML
为快速构建应用提供了非常强健的一套方法。我一般不使用框架的原因是当我尝试适应框架的一套方法的时候需要做更多的工作，相比较仅仅使用Flex框架而
已。对我来说，一个框架需是一个能够让任务变得更简单并且提高生产率的东西，而不是某些我用它只是因为我可以或者因为我想要让自己成为一个更好的开发人员
而去使用。
就如本文开头写的，我在一个电话面试中所提到的，在给出为什么我没有选择使用一个框架的解释之后，采访者这样反应,"我必须在一个巨大的团队中工作。当然啦，你了解我需要多少有些了解框架的啦"。少许思考之后，我知道了他的意思。
使用框架的好处之一就是可以标准化一些事情如何被编码。也就是说，如果程序员A 和程序员B使用相同的框架为同一项目的两个部分工作，你可以很确定他们写的是兼容的。所以可能你需要问你自己的另外一个问题就是，你想要强制确定多少结构？
框架非常大量的检测了他们需要多少预定义的结构。如果你是工作在一个大型团队中，你可能想要比做自己的项目更多强制的结构。预定义的结构提
供的团队工作环境的简化和代码的一致性足够弥补你为一个更需要结构的框架创建所有必须的类而增加生产时间和项目大小。相比之下，如果你是一个项目上工作的
唯一开发人员并且你只是需要一些东西来是生活更简单速度更快的开发，然后可能就你需要一个那种不需要强调太多结构的框架来运用到你的项目上。
看起来， 选择一个正确的框架或者选择完全不使用框架，
只是开发人员的目标的一个功能呢个以及在哪个环境创建项目而已。我能给你的最好的建议就是诚实的高速你自己项目需要什么。我知道在我做完我的研究并且写了
本文之后，我放开了对于框架的观念，我认为它们的确实现了明确的需求。