FLEX与Cairngorm框架学习使用心得体会

最新推荐文章于 2024-11-11 16:03:27 发布

wolf_linn

最新推荐文章于 2024-11-11 16:03:27 发布

阅读量4.5k

点赞数

分类专栏：技术文章标签： flex 框架 application mvc 设计模式 command

本文链接：https://blog.csdn.net/wolf_linn/article/details/4377018

版权

技术专栏收录该内容

2 篇文章 0 订阅

订阅专栏

公司近期选择FLEX作为RIA客户端，因此开始了对FLEX的学习和研究。基础知识和简单介绍很多人做了，此处不再多讲。此处是对FLEX中事件驱动、动态化与反射、方法参数-函数式编程、RPC异步调用，Cairngorm框架中的事件机制、MVC的一些学习与分析。尤其是从J2EE、BS转过来的开发人员一定要转变思维模式。

关键字：FLEX Cairngorm

在学习的过程中，有些事情只需要学习怎么做（know how）就行，有些事情必须知道为什么（know why）。这种有区分的学习方式是学习效率的重要保障。

一、 FLEX

1、事件驱动

FLEX的事件驱动模型架构是基于Observer设计模式，以界面事件为中心的。事件以消息形式按照组件层级进行广播。组件如果订阅了该事件，组件的事件处理方法被触发。不同与BS的请求响应模式。

该事件体系分为：

a) 事件触发：可视化组件可以调用dispatchEvent方便的手工触发事件。当然也可以在界面上操作以触发事件。

b) 事件消息广播：事件触发后，触发组件为目标组件，以目标组件为基点向父组件层层广播，称为事件流。

c) 事件捕获与处理：注册了事件监听器的组件的事件处理方法被触发，开始执行事件处理。

d) 事件流控制：默认情况下事件层层广播，直到最高层级的Application为止。当然，也可以对事件进行如下控制：

i. 中断：使用stopPropagation()和stopImmediatePropagation()中断事件流。中断主要用于事件处理完成情况下为避免父组件也接收到事件消息而出现不可预期的行为。（合理利用中断体现了开发人员对所开发软件的控制力。）

ii. 伪装：伪装并非标准技巧。修改事件中的信息，可以将事件进行伪装。主要用于改变控件的默认行为。

iii. 变异：原事件流继续，同时触发新事件开启新事件流，这为FLEX代码增加了无限的灵活性，也大大增加了理解难度。打开FLEX的源码，可以看见很多。

事件驱动模型架构是FLEX开发的中心，没有理解和掌握该模型架构，就不能妄谈FLEX开发。FLEX中大量使用事件，导致代码阅读和理解存在一定困难，所以要学习FLEX必须先花大功夫熟悉事件驱动模型。

2、动态化与反射

动态化和反射是灵活的开发框架必不可少的部分。FLEX的编译机制也很有特点，只能编译Application能够访问（静态或者实例）到的类文件才能够被编译进入SWF中。这种编译机制有效的减少了SWF文件的大小，但是也有个比较大的缺点，就是动态代码开发与运行成为问题。

如果要开发一个灵活的可以二次开发的开发框架，需要有效利用动态化。

a) 将二次开发的代码放入Application可访问路径。

b) 利用反射动态调用代码。

3、方法参数-函数式编程

FLEX另一个特点是方法参数，这点与常用的面向对象语言JAVA有明显区别。有效使用方法参数将带来巨大的灵活性，比如使用自定义方法改变控件属性或行为、回调callback。

方法参数与常用的面向对象语言JAVA有明显区别，原面向对象编程的开发人员需加强理解。

4、 RPC异步调用

RPC异步调用其实也是事件驱动模型的一种应用。RPC调用是FLEX与远程服务器通讯的方式，是企业应用程序中必不可少的部分。

RPC异步调用类似于AJAX异步调用，与平时习惯的请求响应模式的同步调用有很大区别。需要开发人员转换思路加强理解。

二、 Cairngorm

Cairngorm是应用一系列设计模式和软件开发实践开发的FLEX企业应用微架构。其核心是基于FLEX的关键特征和企业应用的架构模式。

1、事件机制

Cairngorm在FLEX的事件驱动模型基础上定义了一套新的事件驱动模型。FLEX本身的事件驱动模型可以认为大部分是基于可视化控件的，FLEX的事件驱动模型的事件流是从目标控件开始层层向上传递知道Application的。

Cairngorm的事件驱动模型的构建是在Application层级用FController构建全局的事件监听器。FController监听到Cairngorm事件后调用对应的Command。Cairngorm事件驱动模型的特点是：直接在Application层级，没有多层传递。并且一个事件对应一个Command一一对应。

Cairngorm的事件驱动模型适合于处理业务逻辑，也仅适合于处理业务逻辑。最好不要用Cairngorm事件来处理界面行为。

2、动态化与反射

Cairngorm没有直接使用反射。但是遵循了FLEX编译器的规定，在Application中引用FController和Service以保证所有Cairngorm的相关代码均被FLEX编译到SWF中，便于在应用中调用。

3、 MVC与多层架构

Cairngorm框架的一个重要特点就是其MVC的多层架构设计，其中FController是其MVC模式的关键控制器。看到有网友介绍Cairngorm的文章对此框架的首要调整就是去掉FCotroller，这就相当于没有利用Cairngorm框架的最大优点。

Cairngorm框架对表现层（View）划分很清晰，View触发事件，FController作为控制器，提交到Command开始的业务逻辑层。

而业务逻辑层的划分就不是那么清晰了，因为业务逻辑层是跨FLEX和后台服务（如J2EE）的。有2种设计方式，第一种是可以大部分放在J2EE的后台服务层，Command、Delegate、Service都只作为代理，这种更加类似与原BS多层架构的逻辑。另一种设计方式可以将业务逻辑全部放在FLEX中，后台服务仅作为持久层，类似于CS双层架构的逻辑。当然也有2种设计方式的混合，部分放在FLEX中，部分放在后台服务中。业务逻辑层的设计与分布是最考验架构设计师能力的部分。