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事件并不会冒泡，所以如果你想要通知其他更高一级的容器，就只能自己来处理了。

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

资源
Cairngorm developer documentation
Developing Flex RIAs with Cairngorm microarchitecture – Part 1: Introducing Cairngorm (Steven Webster and Leon Tanner, August 2008)
Example Cairngorm project
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 提供的数据管理。

资源
Mate documentation
Example projects
Podcast interview with Mate framework creator Laura Arguello
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框架需要创建很多类，这些创建工作会增加生产时间和项目的大小。

资源
Documentation and licensing
Example project
Podcast interview with PureMVC framework creator Cliff Hall
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之后的版本将不再是一个问题。

资源
Documentation and examples
Podcast interview with Swiz framework creator Chris Scott
做出你的选择
虽然还不是很彻底，但是这里提供的信息配合资源，应该能够为你对每个框架的方法，优点以及缺点提供了一个基本的了解。你会怎么从这些框架中选择一个超过其他框架的框架呢？

也许第一个问题是，我是否需要一个框架？Flex 与MXML 为快速构建应用提供了非常强健的一套方法。我一般不使用框架的原因是当我尝试适应框架的一套方法的时候需要做更多的工作，相比较仅仅使用Flex框架而已。对我来说，一个框架需是一个能够让任务变得更简单并且提高生产率的东西，而不是某些我用它只是因为我可以或者因为我想要让自己成为一个更好的开发人员而去使用。

就如本文开头写的，我在一个电话面试中所提到的，在给出为什么我没有选择使用一个框架的解释之后，采访者这样反应,"我必须在一个巨大的团队中工作。当然啦，你了解我需要多少有些了解框架的啦"。少许思考之后，我知道了他的意思。

使用框架的好处之一就是可以标准化一些事情如何被编码。也就是说，如果程序员A 和程序员B使用相同的框架为同一项目的两个部分工作，你可以很确定他们写的是兼容的。所以可能你需要问你自己的另外一个问题就是，你想要强制确定多少结构？

框架非常大量的检测了他们需要多少预定义的结构。如果你是工作在一个大型团队中，你可能想要比做自己的项目更多强制的结构。预定义的结构提供的团队工作环境的简化和代码的一致性足够弥补你为一个更需要结构的框架创建所有必须的类而增加生产时间和项目大小。相比之下，如果你是一个项目上工作的唯一开发人员并且你只是需要一些东西来是生活更简单速度更快的开发，然后可能就你需要一个那种不需要强调太多结构的框架来运用到你的项目上。

看起来， 选择一个正确的框架或者选择完全不使用框架， 只是开发人员的目标的一个功能呢个以及在哪个环境创建项目而已。我能给你的最好的建议就是诚实的高速你自己项目需要什么。我知道在我做完我的研究并且写了本文之后，我放开了对于框架的观念，我认为它们的确实现了明确的需求。

资料来源:http://wiki.actionscript3.cn/index.php/%E9%80%89%E6%8B%A9%E4%B8%80%E4%B8%AAFlex%E6%A1%86%E6%9E%B6#.E5.BF.85.E5.A4.87.E7.9F.A5.E8.AF.86