关于完美的Flex应用框架的思考

自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框架，在第二部分，我将会做一个尝试，提出我对完美的第三方框架的需求。

原文地址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，但是像任何新兴技术一样，它必须不断成熟以继续获得采用率并保留住目前的开发者。