原文地址http://gorillajawn.com/wordpress/2009/06/21/the-perfect-flex-application-framework-part-2-of-2/

在上一部分，我介绍了Flex第三方框架的几个问题，主要是MVC的影响，以及目前主流的三个框架的采用成本。设计模式的历史，特别是Java社区已经让框架在帮助模式应用方面得到了广泛的认同，这篇文章将把焦点转移回能够让开发者简化任务的特色中去，从而使他们能建立用户所需的更快、更简单的应用，这才是第三方框架应该去做到的目标。那么，进一步说假设没人会反对这样的断言，我们来看看什么能构成我的完美Flex应用开发框架。

分离关注（SoC）：

在Flex开发过程中，存在着核心框架外的一种需求，来帮助开发者完成应用代码的分离。在现实中，这不是框架中最困难的或者最有趣的部分，但是有可能使任何框架的必需部分。我个人喜欢Swiz的依赖注入方法来实现这个目标，而且还应该有更多的有趣的功能添加在依赖注入的基础上，因为我们已经在Java中的Spring框架中看到了他们。

客户端数据管理（想想客户端Hibernate）：

RIA引入了客户端数据/状态的概念，在传统基于页面的应用中，开发者从来没有考虑这种可能性，因为所有的状态被保留和记录在服务器上。有了高级的RIA特色，状态经常在客户端改变，但是不是立刻发送会服务器端，这就引发了一系列管理客户端/服务器间数据状态的挑战。因此，出现了对底层结构能支持客户端/服务器之间数据同步的需求。LifeCylce Data Service和Clear Tookit都包含这个特色，来帮助开发者在一定程度上完成这个任务，但是他们依赖特定服务器的实现。在我的理想世界里，这种逻辑应该都在客户端处理，不管服务器提供了什么数据，这样就可以不用考虑是什么技术提供的数据。这种特色估计会在下一个版本的FlashBuilder中出现。

安全特色：

在任何企业应用，都有多种级别的安全考虑，有很多方法和测量来处理鉴权，但是没有很多Flex工具来解决授权。在最简单的表单中，可以将授权分为下面的几种，服务/方法级别，数据级别，过滤用户所看视图级别。安全服务和数据必须处理在服务器上，但是有些东西有必要控制在客户端上。据我所知目前没有多少类库能实现这些普通的需求，我目前的做法是我的chimp组件来做这些，通过Flex的原数据声明来实现。许多其他组件仅仅人工的处理这个组件，还用了特别的处理来添加过滤逻辑在UIComponent中，或者在view states中，理想情况下，这个特色应该内置到任何第三方框架中去。

全局事件总线：

在Mate中，基本上每个事件都被通过Mate事件总线处理，如果有一个全局的事件总线那对于实现RIA一系列特色将有着非常大的意义。然而，处理每一个事件对我来说看起来太奇怪了，我认为Flex事件应该被分为四种类型：

组件内事件：这些事件只在组件内处理并省略，当一个组件有子元素而且他们内部之间需要通讯时就是这种情形；

局部事件：这些事件被组件忽略但是在组件使用的上下文环境中被处理；

全局事件和数据交换事件：系统任何部分想要被通知时用到的事件，例如用户轮廓发生改变了。所以，在我的观念里，总线是完美Flex框架的必须部分，但是不该被使用来处理系统的所有事件（意思是说Mate将所有的事件放在一处是不合适的）；

上面就是我对完美第三方Flex框架的最迫切需求，我相信还有许多有意义的需求应该加到这个列表中去。在写这篇文章时，我总结到有太多的关注点聚焦到Flex框架中了。我描绘出来的几个方面是第三方框架需要弥补的的环节，或者希望有一天被潜在的平台是实现，但是他们都不是开发者在建立企业Flex应用时遇到的最有挑战性的问题。建立Flex应用最大的挑战是Flashplayer虚拟机的质量，Flashplayer必须变得更快、更好来处理内存消耗、垃圾回收，Flex是一个好的平台来建立RIA，但是像任何新兴技术一样，它必须不断成熟以继续获得采用率并保留住目前的开发者。