关于完美的Flex应用框架的思考(Part 1 of 2)

自Flex技术开始广泛应用以来，对于企业级Flex应用开发框架的讨论就从未停止过，这篇文章是对于构成完美Flex框架要素的思考的第一部分，其中评价了主流的一些Flex框架，相信对于广大开发者来说有很大的参考价值。

在过去的十几年中，大多数企业开发的web框架看起来都关注于问题的结构部分，它们实际上为解决问题而构建的应用只提供了很小的价值。看看那些大多数的JAVA框架，它们甚至不去提供一个内置的组件集。此外，在Flex生态圈，事实上所有的主流第三方Flex框架的诞生，看起来主要的目标是为了增强或者允许使用MVC模式，而唯一例外的是Clear Toolkit，它提供了一些有趣的企业特色；Flex带来了一场革命因为它的出现最主要的意义是让开发者大大提高了构建酷绚应用的效率，因此，Flex是一个完整的平台，而且常常是建立理想应用所需的唯一框架。它提供在MVC架构内建立应用的基础设施，和一系列完整的组件来满足企业应用中的各种需求。当审视应用开发的各个组成部分，工程师们应该只带上能满足核心功能和非功能性需求的工具，或者专注于解决项目中存在的风险就够了。有了Flex平台的帮助，你不应该带着这样的假设去做事情：可能还需要加入第三方框架的支持。

话又说回来，Flex确实有缺点而且可以被改进或者用有趣的和有用的方式扩展它，而且，有一个基础设施来帮助开发者进行合理的分离应用代码中的关注点是有意义的事情。坦率的讲，如果采用第三方框架来获取这种基础设施的成本低的话，那么就没有理由来反对引入一个第三方的解决方案。让我们看看几个Flex框架在这个方面的表现如何：

Cairngorm: 采用和长期所有权的成本太高，有大量必须的代码来实现即使是最微小的功能，对于单个开发者来说，需要认真考虑它是不是该值得采用，这种情况下它的作用不是那么明显（The leverage just is not here）。

Mate: Mate解决了分离关注的问题，通过提供给开发者一个全局的事件总线来处理事件，这个方法非常适合构建Flex应用的理想方式。尽管我趋于相信不是所有的事件是全局的，而且可能根本不需要外部化，但是这肯定是迷题（开发任务）的一个重要部分，有一个合理的方法来关联事件，总的采用成本是低的；

Swiz: Swiz跟Mate比较像，它有个有限的外围接口来供开发者学习，它分离事物的主要机制是使用依赖注入，它在语法和易用性上相当的优雅。

以上三个框架中的两个采用成本是底的，他们也只限于解决Flex开发者的几个问题，这就是这篇文章要讲的关于什么是，应该，可能，将会是完美的Flex框架，在第二部分，我将会做一个尝试，提出我对完美的第三方框架的需求。