Flex框架中Cairngorm优点大比拼

首先简单介绍一下Cairngorm框架。大家都知道，Cairngorm是一个广为人知的老牌Flex框架。它是一个微型架构――由一些设计模式组成用来降低团队协作的困难。

　　Cairngorm从Java的世界带来了很多开发理念，并且把重点放在三个关键区域：处理用户动作，封装服务端的交互和业务逻辑，管理客户端的状态和界面呈现。

　　使用Cairngorm来构建一个项目，需要将应用代码分离到不同的包并且继承Cairngorm的类。以下是Cairngorm项目中一些主要的部分和类。

　Cairngorm是一个广为人知的老牌Flex框架，现在我们简单介绍一下它的优缺点，对于大家掌握系统的知识和软件学习的选择具有很大帮助。

　　ModelLocator是一个储存数据的单例，数据表示程序的状态。单例类的性质保证了程序中的所有组件取得的是相同的数据。

　　ServiceLocator是另一个单例，它集中管理所有服务如HTTPServices。同样，由于是单例，程序中的所有组件取得的是相同的服务。

　　业务逻辑被封装在command类中。command实现了命令模式，它们表示相应用户事件的逻辑。

　　事件被类FrontController处理，FrontController会把事件映射到相应的Command。

　　Delegate类作为代理来对远端服务进行请求和响应。

　　优点

　　Cairngorm在Flex社区广为人知，作为Adobe开源项目的一员，拥有活跃的社区和开发者的支持。

　　其次，该框架吸取了Java开发中许多宝贵的经验，并成功得用于大型项目的开发中。

　　并且，Cairngorm适用于团队开发，因为它提供了结构化的开发方法来创建应用，利于分布式的开发。

　　其次,Cairngorm实现了自己的一套事件处理的方法。这增加了Flex内置事件模型的复杂度，而且它还有限制。由于每个事件都有自己的的command，事件的响应者被限制成1个。加之Cairngorm的事件不具冒泡特性，如果要发送数据到容器的其它层次则需要自己来实现。

　　第三个常见的批评是Cairngorm依赖全局的单例，这让模块和单元测试变得困难。尽管可以打破单例中的模型简化测试，但是会增加额外的过程。

缺点

　　需要写大量的类应该是Cairngorm最多的负面评论了。在Cairngorm中，每一个event对应一个command；因此，需要对程序触发的每一个事件来写一个command类。而且，还要为command写一些其他的类，例如delegates。即使是一个中型的应用也会导致大量的类产生。