日期:2013-11-24  浏览次数:20706 次

  此篇教程由本人在法国的朋友章鑫杰为本站提供,所有内容均由作者本人手书.网站:http://www.openvue.net
btw:作者本人现从挪动领域的开发,本来应还有更多的章节,但由于任务较忙,不能完成后续的章节.些教程中的四节,次要是针对macromedia组件的探讨.如果你对macromedia组件有兴味或是对你现有的开发不知到底使用哪一种方式来做,也许会适合你.

我向来觉得Flash MX 2004是一个面向程序员,尤其是Java,C#程序员的产品,从这款产品你可以看出Macromedia的发展方向,它要让Flash及其配套的服务器端产品成为电子商务的次要开发平台。从程序员的角度学Flash MX 2004,我最关注的是它背后的程序设计模式,它用XML非常好的融合了表现层,两头层,和数据库层,是设计数据库网络使用程序,或者说电子商务类程序很好的开发平台,并提供了一套非常强大的组件来加速开发进程,很多人学MX2004,只关注它的UI Component,这是皮毛,它的精髓在于和数据库相关的几个组件。

让我们站在高处来看一看这几个非常重要组件,大致了解一下在Flash MX 2004这么个环境下,一个典型的数据库使用程序应该怎样编。

首先,用Connector(包括XMLConnector, WebServiceConnector,RemotingConnector)来连接服务器,取得原始数据,这些原始数据普通要求是XML格式的,RemotingConnector除外,这些数据取得后,进入DataSet做一个缓存和数据格式的转换,这就是.NET和J2EE里面的Offline Database的概念,这不但可以融合不同数据源的数据,而且通过缓存可以大大提高效率。DataSet里面的数据可以通过Binding连接到UI Component上去,每个UI Component都有一个Binding面板,你可以把它们关联到DataSet。这样你只需求写一行代码就可以把数据展现给你的用户,就是:xmlconnector.trigger() 或者webservice.trigger()。Trigger命令会连接服务器并取得数据,剩下的任务由于你曾经设置了Binding,所以数据自动在组件两头流动。

那么数据在客户端被修正后怎样传回服务器,进而把这些修正反映在数据库呢?Flash MX 2004为我们提供两个非常强悍的组件:RDBMSResolver和XUpdateResolver,这连个组件可以和DataSet关联,DataSet会把用户修正的数据按特定的格式传到这两个Resolver上去,RDBMSResolver用的格式是Macromedia本人定义的,很简单的格式,你可以在他们网站上找到参考材料。XUpdateResolver用的是XUpdate格式,是一种标准格式,很多Xml数据库都用它作数据库更新言语。这样DataSet可以自动通过Resolver连接服务器来修正数据。

你看,整个过程实际上不用怎样写代码,只需求设置一些属性,拖拉一些组件,把它们邦定一下就可以了,是不是很简单呢?

  在(一)中我讲到Flash MX 2004有三种Connector,即XMLConnector, WebServiceConnector,RemotingConnector,如果你的Flash编辑环境中没有RemotingConnector,请到Macromedia的网站上去下载。

XMLConnector是最简单的一种连接器,服务器端可以是任何言语的脚本,ASP,PHP,JSP等都可以,它的好处是服务器程序不需求加载额外的库,只需你前往的内容是XML的就可以了。这样实际上方便了程序员用最少的成本将原有的服务器端脚本稍作更新,以配合Flash富客户端。它的坏处在于,这样的脚本使前后台程序员之间的配合比较困难,由于它的接口是隐藏的,由于如果你不能和脚本开发人员密切沟通,你对接口和参数的信息就一无所知,至少不全面,甚至不知道其中能否有后门。但如果你既开发前台又开发后台另当别论,另外很多习惯于传统的Web服务器脚本开发的人员也可以比较快的上手。

我们跳过WebServiceConnector,讲讲RemotingConnector,这个连接器基于Flash Remoting 技术,有不少的朋友很热衷于Remoting技术,但我并不是很看好它。应该说Remoting 技术的设计思想和Flash的SWF文件格式的设计思想是一脉相承的。它们都极力的强调带宽的重要,对于在Internet上传输的内容要尽量的精简,紧缩。由于前一阵子,我曾经想开发一个J2ME版的Flash Player,所以我对SWF格式做过比较深入的研讨,它在紧缩方面做的相当到位,每一个bit都尽量利用,Remoting也是希望通过二进制字节流减少传输量来提高效率,所以我说它们的出发点是一样的。Remoting在本质上属于RPC的一种,它和DCOM,CORBA,JAVA RMI属于一类的技术,不同之处在于Remoting 的通讯协议采用HTTP,这样它就具备了WebService这样的跨越多个域,跨越防火墙的功用。在效率上Remoting毋庸置疑要高于WebService,但这不是我们取舍一个技术的决定要素,要不然,DCOM,CORBA这些东西的功用更强悍,但他们在Web时代却得不到广泛的使用。另外,Remoting是Macromedia的“私有财产”,MM拥有绝对的自动权对它进行修正和扩充,就像MM对Flash格式和AS进行大刀阔斧的改革一样,开发人员是很忌讳这种事情的。虽然MM地下了Remoting AMF通讯协议的大部分内容,但它实际上故意对媒体流的传输协议秘而不宣。很多人热衷Remoting很大程度上受了MM那个视频聊天DEMO的诱惑,而实际上为了要视频聊天,你需求付出惨重的代价,首先服务器必须用MM的软件,由于没有第三方知道怎样和Flash客户端交流媒体流,而MM的服务器软件按照connection收钱,贵的吓死你,用盗版另当别论。基于以上缘由,我团体比较不赞成使用Remoting.

WebServiceConnector我放在最后讲。这是目前最有前途的RPC技术,有人说WebService 是个很蹩脚的技术,由于Microsoft的极力推广才有它的今天。我对此不以为然,抛开对Microsoft的成见,它所推出的技术普通都相当成功,就像如今的.NET, C#,作为一个程序员,我只能用艺术品来描述它们。WebService 也许不是一个最完满的技术,但在当下,它最适合Web分布式计算。时至今日,它曾经越来越成熟,而且在很多世界级的大型项目中得到了使用和考验。一个技术它被使用的越广泛,其价值也就水涨船高,它带来的一个明显的好处在于,你可以不用被绑死在一个开发平台上,无论是服务器端还是客户端,比如如果有一天你的客户要求你用SVG或者Java Applet开发客户端,由于你在服务器端采用了WebService,就可以很快的跨越到另一个客户端技术。不要以为这种情况不太会发生,实际上如果你看过SVG 2的技术文档,你就会发现Flash有一天很可能会被它取而代之,它真的很强大,也很适合开发富客户端使用程序,这时候你的服务器脚本如果采用了Remoting 技术,你可惨大了。再者,从开发环境而言,象VisualStudio.NET,WebSphere,JBuilder 等都对WebService提供了相当好的开发和调试环境。绝对于XMLConnector,WebServiceConnector的优点还在于允许你在设计时(DesignTime)绑定(Binding)它的参数(Paremeters )和结果(Results)。比如你可以绑定你的复选框(CheckBox)到WebService的一个参数上,复选框里的选择内容被改变时,WebService被触发(Trigger),WebService连接服务器从数据库中取回新的数据更新DataSet,然后DataSet又更新和它邦定的其他组件,你看一个Master-Detail结构的数据库使用程序就这么简简单单的生成了,这个过程你真正要动手编的程序可能只要3,4而已。

总结:如果服务器端允许,你也具备一定的WebService编程经验,最好采用WebServiceConnector。尽量避免使用Flash Remoting。XMLConnector的使用取决于你项目的具体情况,比如规模,开发模式,能否需求重用大量的已有脚本等。

  我在这个教程的前几篇里面,我尽量让大家站在高处看Flash MX 2004在数据库编程方面框架性的东西,知其然知其所以然,帮大家逐渐分析每一个组件它的功用和MM为什么会推出这些组件,而不是其他的。在教程的最后我会给出一个比较复杂的例子让大家动动手。

这节,我们来分析Dataset这个东西,这是MX 2004数据库编程框架里面灵魂性的组件,是核心。MM的Flash 2004出来的很晚,故此它无机会从微软的.NET和Sun的J2EE中吸取了不少营养。Dataset就是MM博采众长后搞出来的一个非常棒的数据库