Flex3企业级Web应用系统设计与实现.docx
《Flex3企业级Web应用系统设计与实现.docx》由会员分享，可在线阅读，更多相关《Flex3企业级Web应用系统设计与实现.docx（37页珍藏版）》请在冰豆网上搜索。
Flex3企业级Web应用系统设计与实现
Flex3企业级Web应用系统设计与实现 姜天格
企业级Web应用系统需要多人团队并行开发，如何能够适应这种开发模式是设计系统架构的重点。
设计良好的系统架构应该像拆积木那样能够拆分成为不同的部分，这些部分功能上相对独立，便于多人开发而不会相互影响。
同时，又能够像搭积木那样方便地组合，完成复杂的功能。
本书从企业级Web应用系统设计中实际需要解决的独立技术问题出发，提出问题，分析问题，解决问题。
然后又将独立的技术要点结合起来，搭建企业级Web应用系统的开发框架雏形。
本书的实例采用Flex2，AmfPHP，PHP，MySQL技术。
本书适合有Web应用系统开发经验的系统设计人员和软件工程师参考
第1章 接触Flex技术
Flex技术作为开发Web应用的利器，近年来越来越被重视。
在本章中，我们将从Web应用发展的角度，阐述Flex技术在其中发挥的作用。
同时说明Flex技术中一些重要的概念。
1．1 Flex与Web应用的发展
互联网的普及不过短短十几年的光景，其由最初的浏览静态信息快速发展到动态搜索和多媒体应用。
随着网络软硬件技术的进步，大多数的数字信息化应用可以通过网络模式来实现。
在网络上运行着的各种网络应用程序，我们可以统称其为Web应用。
下面从使用者（用户）和开发者两个群体的角度，阐述Web应用的发展方向。
1．1．1 用户对Web应用的期待
通过网络获取信息，是目前大多数网民上网的主要目的。
随着网络技术的进步，获取信息已经不是问题，我们开始关注网络"体验"，要让上网的过程成为一种享受，特别是在视觉和操作方面。
如何提供更具魅力的Web应用视觉效果，如何让操作更加人性化，更加有趣味性，都是需要改进的地方。
用户对网络生活充满了期待，我们可以大胆地想象：
随着科技的进步，未来的Web应用可以提供给人们日常生活所需要的绝大部分内容。
而且，我们可以从Web应用中得到视觉、听觉、味觉、嗅觉等全方位的感官体验。
1．1．2 开发者对开发技术的期待
PHP、ASP、JSP等是开发Web应用的常用客户端（浏览器）技术。
它们都是脚本语言，需要依赖浏览器的动态解释才能够正常显示和执行。
非"所见即所得"的开发方式给代码调试带来难度。
在Web应用的开发过程中，界面外观的调试非常耗费工时，而且往往同一代码在不同的浏览器、同一浏览器的不同版本下会有不同的外观和不同的动作效果。
开发者非常期待能够解决上述问题的方法的出现。
脚本语言编写的界面外观表现力有限，且多为静态效果，这也是Web应用需要改善的地方。
1．1．3 Flex带来的新气象
Flex技术能够为Web应用带来哪些改进呢？
就目前Web应用所处的发展阶段而言，网络技术能够做到的事情还有限，不可能"大跃进"似的发展。
着眼现在，我们更多地是从丰富Web应用的内容、提高用户操作体验着两方面来考虑改进Web应用。
丰富Web应用的内容是永远的课题，不在本书内容之列。
我们主要说说如何通过技术手段，提高用户操作体验。
如果你接触过Flash，就知道它有很强的视觉表现力，动态效果非常好。
Flex是Flash的姊妹，同样具有非常强大的功能。
作为开发Web应用的利器，非常值得期待。
对于开发者而言，采用Flex开发Web应用，能够彻底地实现MVC的架构思想，把用户操作部分的逻辑完全地从服务器端代码中分离出来。
这能够大大简化系统架构的复杂性，对今后Web应用的设计产生本质的影响。
Flex开发出的对象是扩展名为swf的文件，通过浏览器的插件FlashPlayer（运行时环境）解释执行。
由于swf文件是经过编译的中间代码，所以源代码不可见，安全性又提高了一个级别。
Flex技术的种种优点，使它进入了开发者的视野。
实际的Web应用中也越来越多地看到它的身影
1．2 Flex技术相关概念
Flex是Adobe公司的产品，它是Web应用的开发平台和工具。
Flex是一系列发展中的技术和产品线的概括词,包括FlexFramework,FlexBuilder和服务器端产品（FDS）等。
2006年6月，Flex2正式版发布，标志着Flex技术已经成熟，加速进军Web应用领域。
细心的你也许发现周围采用Flex技术的Web应用越来越多。
但是，由于Flex产品价格昂贵和占用网络带宽资源的缺陷，在网络带宽还是一种稀缺资源的今天，Flex技术并没有得到大范围的普及。
目前中国的市面上甚至没有几本介绍Flex的书籍。
Adobe公司也充分意识到了Flex产品的不足和缺陷，在持续改进中。
并于2008年的2月推出了最新版本Flex3，免费开源了FlexSDK。
同时，Flex3中的很多新技术某种程度上解决了带宽资源占用大的问题。
对于很多Web应用的开发人员而言，Flex仍然是一项新技术，对其中很多概念的理解可以说是仁者见仁，智者见智。
在本节随后的内容中，我们将对一些重要的概念一一进行阐述和说明，对这些概念的理解非常重要。
1．2．1 RIA与Flex
RIA是RichInternetApplications的缩写，译为富互联网应用程序（或富Web应用）。
"富"与"瘦"是相对的概念。
互联网发展至今，呈现给用户的界面外观仍然非常单调。
通过诸如PHP、JSP等脚本语言描绘的界面外观需要由浏览器解释执行。
这些脚本语言本身的处理能力有限，浏览器能够解释的脚本也有限，这大大限制了用户的操作体验。
对于这种不丰富的表现力和操作能力，我们称其为"瘦"。
这样的互联网应用程序就是瘦互联网应用（我们身边的绝大部分网络应用是"瘦"的）。
RIA就是在这种背景下提出的改进Web应用现状的概念。
富互联网应用程序"富"在哪里呢？
主要是两个方面的体验：
丰富的视觉体验。
丰富的界面操作体验。
Flex、Flash、SilverLight（微软产品）都是实现RIA的技术。
1．2．2 RIA既是C/S又是B/S
RIA是纯粹的B/S（浏览器/服务器）模式的系统，但是为什么又说它是C/S（客户端/服务器）模式的系统呢？
C/S模式的系统最大的优势在哪里？
在于客户端程序能够分担服务器的大部分的功能，从而降低服务器负载，降低系统架构的复杂程度。
RIA是否也具备C/S系统的优势呢？
当然具备。
1．2．3 RIA的未来
对RIA应用持否定态度的人主要有两个理由：
Flex等技术实现的RIA应用程序的体积都较PHP，JSP界面程序大很多（通常有数量级的差别）。
界面程序的下载不但严重占用了有限的带宽资源，还使下载时间增加。
由于用户不愿意长时间等待，可能造成用户放弃使用RIA。
Flex还没有免费。
对此，让我们思考如下事实：
大家都知道摩尔定律，从我们接触计算机开始，其性能便发生着日新月异的变化。
网络曾经只属于科研院所和一些特定的机关单位，现在已经是"飞入寻常百姓家"。
目前国内有限的带宽资源的确束缚了RIA的发展，但是应当了解到中国的网络还处于发展水平，欧美国家早已走在前面。
我们的邻国日本已经把光纤入户作为2010年要实现的目标之一。
带宽，这个目前还在困扰着中国RIA应用发展的拦路虎，在不久的将来，必定不再成为问题。
从另外一个角度来看，RIA的一个重要应用领域是企业内部，目前的企业内网通常非常快，其带宽足以满足企业内部RIA应用的需求。
至于Flex的费用问题，对于个人而言，的确是价格昂贵。
但是对于有RIA需求的企业而言，软件的投入是必需的，投入的资金缔结了企业与软件厂商之间的法律关系，确保了一旦软件发生问题，将由软件厂商负责承担责任。
对于企业，免费的午餐未必是最恰当的选择。
Adobe公司也有其产品战略，在未获得市场垄断地位之前，调整产品定价，也必然遵从市场趋势，向消费者一边倾斜。
Flex程序在客观上有着雄厚的"群众"基础。
据统计，世界上超过9成的电脑安装的是Windows操作系统，而Flex程序的运行时环境"FlashPlayer"是预装在Windows操作系统中的。
也就是说世界上绝大多数的电脑都已经具备了运行Flex程序的条件。
需求引导着市场，RIA既具备C/S模式系统的优势，又兼备B/S系统容易部署的优点。
我们还是应该乐观地看待以Flex为代表技术的RIA的发展。
1．2．4 Flex与Flash的关系
Flex与Flash都是Adobe公司旗下产品。
Flash最初的产品定位是二维矢量动画制作工具。
随着产品功能的增强，Flash和Java等服务器端代码相互配合已经能够开发RIA系统。
但是，由于Flash的产品定位，使得它更多体现的是如何开发二维矢量动画。
贯穿开发过程中的最主要的概念是层、时间轴。
开发二维矢量动画和开发Web应用程序是两个完全不同的领域。
Flash中层、时间轴的概念对于Web应用程序的开发者而言，是完全陌生的。
对层和时间轴的操作也是与Web应用程序通常的做法格格不入的。
一个现实是：
Flash程序的开发者不善于开发应用程序，而应用程序的开发者通常又不善于开发Flash程序。
为了占领RIA的市场，Adobe公司推出了Flex。
Flex和Flash采用了相同的底层技术，并增减了一些功能。
Flex和Flash的操作界面完全不同，这是为了适应应用程序开发者的思维方式和使用习惯。
对于Flex与Flash的关系，我们可以这样理解：
它们的底层技术是相同的。
Flex能够实现的功能，Flash同样能够实现；但是Flash能够实现的功能，Flex不一定能够实现。
它们的应用方向是不同的：
Flash主要是为了开发二维矢量动画；Flex是为了开发RIA。
它们的使用者是两种不同的人群：
Flash的使用者主要是二维矢量动画设计师；Flex的使用者主要是应用程序开发人员。
因此两种工具表现风格和操作方法上有非常大的区别。
Flex程序和Flash程序可以通过某种方式进行交互。
1．2．5 Flex是"客户端技术"
RIA系统运行流程如图1-1所示：
Flex程序能够完成大部分的功能。
通常只是在需要的时候，与服务器端程序进行必要交互。
交互的只是必要的数据。
客户端的Flex程序能够完成相对独立的完成功能，服务器端程序只是起到一个数据保存者、数据提供者的角色。
从这个意义上来说，Flex是客户端技术。
有的开发者认为Flex不单是客户端技术，还包服务器端技术。
没错，似乎Adobe公司目标要把Flex产品发展成为一个"全能"的RIA应用开发工具。
例如，Flex可以直接操作某些数据库。
但是请不要忘记，古话有云：
术业有专攻。
每一种开发工具都是经过长时间的完善才有可能在某一领域突出优势。
以开发RIA系统客户端为卖点的Flex技术如果想染指.Net和Java等成熟技术的市场，未免有些贪心不足。
况且，RIA客户端技术目前还有许多亟待解决的问题，不能说已经真正在RIA开发领域站稳了脚跟。
对于开发者而言，采用成熟技术进行恰当的组合是目前明智的选择。
1．2．6 Flex三种通信方式
Flex程序与服务器端程序进行数据交互，有三种通信方式：
表1-1
通信方式
通信协议
交互数据格式
HttpService
常用的http协议
XML
WebService
SOAP协议
XML
RemoteObject
Flex自定义的高效二进制
数据通讯协议：
AMF
任意（可以是数字，字符串，对象，图片等等）
这三种通信方式的比较如下：
表1-2
通信方式
优点
缺点
HttpService
数据格式通用，便于不同应用系统间交换数据
1． 数据在发送前需要转换成XML格式，接收后要解析XML数据。
哪怕是只发送一个简单的的数字也要如此
2． 在处理复杂数据类型如图片，对象的时候，非常不方便
WebService
同上
同上
RemoteObject
能够处理各种类型的数据类型，速度快
需要专门的服务器端软件LCDS（FDS）或AmfPHP。
LCDS（FDS）是收费的，价格不菲
1．2．7 LCDS/FDS与AmfPHP
Flex支持Adobe公司自定义的一种通信协议：
AMF。
这种通信协议能够把数据压缩后进行序列化，以二进制形式进行传输。
具有数据安全性高，传输快的优点。
当Flex程序采用AMF协议与服务器端程序进行数据交互的时候，服务器端程序也必须支持AMF协议，这样才能够解析AMF格式的数据。
如果服务器端程序采用JAVA语言开发，那么需要安装Adobe公司的服务器端产品LCDS（FDS）。
如果服务器端程序采用PHP语言开发，那么需要安装第三方软件AmfPHP。
表1-3
Java
PHP
Flex2
FDS（FlexDataService）
AmfPHP
Flex3
LCDS（LiveCycleDataService）
我们以AmfPHP为例，对图1-1进行修改：
（点击查看大图）图1-2
1．2．8 MVC框架与Flex
在1．1．2节中，我们提到了Web应用开发通常使用MVC框架，从MVC架构的角度来说，Flex就是其中的V（视图）。
采用Flex技术的MVC框架有什么有特点吗？
有。
采用Flex技术的Web应用是最彻底的MVC的架构。
界面（客户端）的开发和服务器逻辑的开发完全分离开，因而使得MVC架构的Web应用更容易设计，开发效率得到提高，复杂程度降低。
1．2．9 Flex开发框架
当我们在规划某个Web应用的时候，经常想到的是采用什么样的应用程序框架，比如Struts。
采用框架的确能够能够迅速地建立起Web应用的骨架，但是近来有一种倾向：
开发者们过于想要在项目中使用框架，以至于不去考虑这样做是否有必要。
应用程序框架带来便利的同时，我们还要思考它的另一面：
需要付出时间成本：
你需要深入学习以便能够完全掌握使用它的方法。
某些场合下，使用框架反而使得程序变得复杂：
框架内定了程序运行的流程，不管是否需要，你都要按照规定编写代码，而有些可能是不需要的。
现在，已经出现了很多Flex程序的开发框架。
知名的如Cairngorm，Model-Glue等。
对于MVC架构的Web应用系统而言，Flex实现了V（视图）功能。
是否有必要对视图部分进一步采用局部框架（Cairngorm，Model-Glue等）？
这样做是否过犹不及？
对于这个问题，仁者见仁，智者见智。
1．2．10 Flex操作本地/跨域资源
想象一下，如果你从某网络站点下载的程序有足够的本地操作权限：
可以读写文件、创建文件、删除文件。
那么你是否担心它是黑客程序？
同样的道理，你是否信任某个不熟悉的网络站点，使用它提供的程序或内容呢？
显然你不会那么轻率地相信陌生人。
因此，出处于安全考虑，Adobe公司限制了Flex程序操作本地资源的能力。
同时在没有经过用户的授权的情况下，也不允许Flex程序使用其他跨域网络站点的内容。
1．2．11 AIR与Flex
Flex程序是运行在浏览器中，由浏览器插件FlashPlayer负责解释执行的。
用户的计算机上不需要安装客户端程序。
这也正是C/S模式与B/S模式的根本区别。
B/S模式的Web系统不能够充分利用用户计算机的计算能力和文件系统资源。
Flex技术开发的Web系统也是如此。
为了能够像C/S模式的系统那样，充分利用用户计算机的计算能力和其他资源，Adobe公司推出了C/S模式的系统：
AIR（AdobeIntegratedRuntime）。
它允许开发人员利用他们现有的网络开发技术（如Flash,Flex,HTML,JavaScript,PDF）在用户计算机上永久驻留客户端程序。
很可惜，目前的Flex技术还不能像VB、JAVA那样深度地使用计算机资源。
因此目前AIR系统只是扮演着眼高手低的尴尬角色。
1．2．12 是否使用会话（Session）
有这样一种看法：
Flex程序与服务器端的交互不需要刷新界面，能够保持状态信息，因此采用Flex技术的Web应用不再需要用服务器端会话（Session）来保持状态信息。
上述的看法忽略了一个重要因素：
服务器安全。
身分验证状态信息必须保存在服务器端会话中，如果不这样，一个来访者声称他是超级管理员，服务器如何判断身份的真伪呢？
完全放弃服务器端的会话，是不正确。
下图是服务器端会话身份严整的原理图：
（点击查看大图）图1-3
1．2．13 Flex中文字体
Flex产品目前只有英文版和日文版，对于除英文以外的其他语言字体支持的不是很好。
对于中文，可选的字体只有Windows操作系统自带的常见的两三种，如果要在Flex程序中使用其他中文字体，方法只有一个，就是把该字体嵌入并编译到Flex程序中。
这种做法的缺点是使得Flex程序的体积变得很大。
Flex中有很多特效，比如文字的旋转。
这些特效只对编译到Flex程序内部的字体有效果。
如果字体没有被编译到Flex程序内部，则特效不起作用。
日文汉字也存在同样问题。
1．2．14 FlexFramework与Flex程序"瘦身"
Flex程序体积很大。
与相同功能的PHP、JSP脚本程序相比，往往有10倍，甚至100倍的差距。
如果用户网络速度很慢，那么浏览器在下载Flex程序的时候就需要很长时间。
这是用户无法接受的。
因此，必须想办法减小Flex程序的体积。
我们先了解一下Flex程序体积大的原因，见下图：
（点击查看大图）图1-4
FlexFramework是Flex的核心。
内容包括Flex组件（按钮、输入框等）的定义、组件的动作定义、底层类、公共函数等等。
上图中，编译后的Flex程序不但包含源程序部分，还包含FlexFramework中的相关内容（源程序中用到的各种Flex组件）。
上图中的源代码只有短短的8行内容，但是经过编译后的Flex程序test.swf的大小竟然达到了124KB。
将源程序以外的内容从编译后的Flex程序中剥离出去，是瘦身的根本方向。
在编译Flex程序的时候通过指定编译参数达到此效果。
这就涉及到RSL（RuntimeSharedLibrary）的概念，我们将在第5章具体说明相关内容。
将过度集中的功能分成多个独立的Flex程序，也是瘦身的重要方法。
同时这也是中大型Web应用设计的主要方法之一。
1．2．15 浏览器缓存和永久缓存
浏览器具有缓存功能，可以把Web应用的一部分保存在内存当中。
这样，同一Web应用的不同的浏览器页面就可以共享内存中的内容，而不必从服务器端多次下载这些相同的内容。
浏览器缓存能够减少浏览器和服务器交互的次数，减轻了服务器的负担，节约了有限的带宽资源。
浏览器缓存中的内容随着浏览器窗口的关闭而被清除。
因此，我们也可以称浏览器缓存为临时缓存。
当你下次访问相同Web应用的时候，你仍然需要下载曾经的缓存内容。
能否把浏览器缓存的内容永久地保存在用户的计算机上呢？
Flex3提供的永久缓存的功能（Flex2只能实现浏览器缓存）。
通过在编译Flex程序的时候把FlexFramework和程序的公共部分指定为RSL（RuntimeSharedLibrary），就能够达到永久缓存的效果。
这是FlashPlayer的内部机制，我们不必深究。
1．2．16 SWC文件
我们在开发软件系统的时候，通常都会把一些公共的部分（包括公共函数、图片或其他资源）事先做好，供其后程序开发使用。
在开发Flex界面程序的时候，也是如此。
那么，公共部分是以何种形式提供给开发者呢？
是原封不动地提供源代码，还是将公共部分封装成一个程序包，然后提供这个程序包呢？
当然是提供程序包更加方便。
开发者只需要将程序包放置到开发环境的指定位置，就可以通过指定库文件的形式把该程序包导入到开发环境中直接使用。
另外，由于程序包是经过编译的程序集合，所以看不到源代码，更无法修改，因此保密性更好。
Flex技术中，扩展名为"swc"的文件就是这种程序包。
使用外部程序包（swc文件）的Flex程序在编译的时候有两种选择（通过编译参数来指定）：
把外部程序包中被使用的部分编译进Flex程序中。
见图1-5。
与上面的情况相反，不需要把被使用的部分编译进去，只需要被使用部分的定义信息编译进Flex程序中即可。
见图1-6。
（点击查看大图）图1-5
（点击查看大图）图1-6
这两种选择有什么本质上的不同吗？
有。
第一种选择的情况下，Flex程序的运行不需要外部程序包。
第二种选择的情况下，必须将外部程序包方在Flex程序能够找到的地方。
供其动态调用。
后一种选择，形式上就是RSL。
1．2．17 RSL
RSL是RuntimeSharedLibrary的缩写。
翻译成中文就是：
运行时共享库。
它的表现形式是swc文件。
从字面上我们可以理解到：
RSL是Flex程序运行的时候需要的库。
RSL的应用请参见图1-7。
（点击查看大图）图1-7
RSL是与Flex程序物理分离的独立swc文件。
当客户通过浏览器下载Flex程序之后，由FlashPlayer负责解释执行。
FlashPlayer在解析Flex程序结构的时候，发现该Flex程序使用了某个RSL，于是FlashPlayer就马上从服务器端下载该RSL，并存放在浏览器缓存中或FlashPlayer指定的客户机硬盘的某个地方。
对于后者，由于该RSL被保存在硬盘上，不会随着浏览器的关闭而消失，所以又被称为永久缓存（参照1.2.15节的内容）。
RSL是某个Web系统中全部或部分界面程序的公共部分。
从其内容的性质上分为两类，见表1-4。
表1-4
RSL类型
缓存性质
说明
自定义
浏览器缓存
把自定义的Flex公共程序集合指
定为RSL，只能是浏览器缓存
FlexFramework
永久缓存
指定FlexFramework为RSL，
则成为永久缓存
1．2．18 异步执行模式
传统的由PHP、ASP或JSP等客户端技术编写的Web应用，其执行模式属于同步执行。
向服务器发出请求之后就一直等待响应结果的返回，其间不能进行其他处理。
采用Flex技术的Web应用的执行模式属于异步执行。
异步执行的本质是多线程。
Flex程序向服务器发出请求之后，FlashPlayer会另外启动一个线程来等待服务器的响应结果。
而主线程将继续向下执行。
因此，采用Flex技术设计Web应用的时候必须要留意程序执行上的时序差异。
举例来说，同步执行模式下，对于服务器返回结果的处理可以安排在服务器程序调用语句之后。
而在异步执行模式下，对于服务器返回结果的处理就必须安排在被启动的线程中，因为只有这个线程才能在某个不固定的时间得到服务器返回的结果。
（点击查看大图）图1-8
上图中，Flex程序的某个处理有6条语句；服务器程序A有5条语句；用来接收结果的程序模块有3条语句。
时刻1：
Flex程序的第3条语句执行后，服务器程序A开始执行的同时，用于接收结果的线程也被建立，等待结果的返回。
而Flex程序将继续向下执行。
时刻2：
Flex程序已经执行完毕。
服务器程序A仍在执行。
线程处于等待状态。
时刻3：
服务器程序A执行完毕，返回结果。
线程接收到结果，然后调用与线程绑定在一起的程序模块，用来处理接收到的结果。
1．2．19 Flex程序与浏览器的关系
Flex程序是通过浏览器（如IE）间接和服务器交互的。
这个概念非常重要。
Flex程序被下载到浏览器中，由浏览器插件FlashPlayer负责解释执行。
Flex程序向服务器发出的请求信息实际上是调用浏览器的发送功
升级会员 