< type="text/javascript">
我个人工作中有过web、RCP、RIA等方面的经历,对图形界面技术以及其趋势,有过深入的思考,这里写下我的见解,欢迎大家讨论。
下面我们将讨论CS ajax RCP RIA等
一、过去技术总结
CS技术:CS技术的C部分,本质上是用某种语言,调用本地widget作为图形用户显示界面,并用某种语言相应事件处理和业务处理。
BS技术:BS技术的B部分,本质上是用HTML,调用(通过HTML解释器)容器内的widget作为图形用户界面,并且用某种语言相应事件处理和业务处理。
CS技术的缺陷是C部分庞大,部署麻烦,并且平台兼容性不好。BS的缺陷是B部分信息展示能力太弱,并且(通用的JS语言的)事件和业务处理语言功能太弱。比如随着企业的业务发展,SAAS已经是一种实际市场:一方面是众多中小企业,需要便宜强大的企业信息服务平台,而同时不必负担开发费用,维护费用,服务器费用等等。另外一方面阿里软件、浪潮软件等公司已经对此市场进行了很多投入。但是BS模式不能满足企业级应用复杂的信息表现形式、不能满足操作的快捷性、软件的强壮性等。
二,AJAX技术的缺陷
A,BS软件不适合复杂的页面表现形式
首先,最简单的树在BS里面都是一个不简单的问题,还有各种各样的表格,以及表格的排序、可编辑表格。。。。等等数据表现形式
其次,多个widget或者页面之间数据互相关联,有一定业务联系,在BS上表现这种关系的时候,可以实现,但是编程量比较大。
B,BS不能满足操作的快捷性
BS也可以实现快捷键,但是限于简单的数据表现能力,很多业务不得不通过比较笨拙的方式表达出来,限制了快速便捷的操作,这些对操作熟练度比较高、操作速度比较快的企业需求,也有些不满足。
C,BS软件的强壮性差
如果用BS软件实现了AB,那么需要其业务和事件语言操作比较大量的数据,进行比较复杂的业务运算。另外,还需要此语言对HTML的进行很多“修改”操作。在我过去实际的应用中,我发现JS语言的能力实在是相当有限,首先是大量数据的操纵能力他不行,其次复杂的运算能力他也不行,第三过多的HTML操作,导致内存问题很严重,浏览器容易崩溃。
三、富客户端技术
面对这些缺陷,很多人思考了:我们需要一个有BS和CS优点的图形技术——跨平台的、快速部署的、有强悍的展现能力和强大的业务事件语言。
在我的想象中
1,要实现跨平台,这种UI技术必须将widget组件包含在一个容器中提供出来,这个容器要么在任何操作系统人都有,要么随URL请求一起被下载过去。
2,要实现快速部署,这种UI的表现形式最佳是文本,UI类似HTML那样被分割成很多HTML(JSP/ASP/PHP/....)文件,这个UI被请求以后,在容器内被解释和展现。事件脚本随之被下载,到客户端执行。
3,要有强悍的展现能力,他的widget必须丰富
4,要有强大的业务能力,他的客户端事件和业务语言必须强大。另外,这种语言也必须随容器提供或者OS上具有。
IBM提出了RCP概念,ADOBE提出了FLEX,SUN提出了webstart,微软提出了XAML和银光。
1,RCP
RCP是一种伪富客户端技术,他其实和过去的CS技术没有区别。他相对之唯一的优势就是跨平台。基本上就是CS+widget容器
2,FLEX
基本符合所有要求
3,XAML和银光
XAML不跨平台,基本符合所有要求。鉴于此,微软提出了银光这个东西
4,webstart
对于条件1,通过装虚拟机实现
对于条件2,webstart将所有UI打包到一个文件中,第一次使用的时候一次性下载过去,对网速要求很高。现在的网络条件用起来非常不爽——这种方式,UI同步的技术大家要注意:是全部同步还是差异同步,我并没有研究过。
对于条件3,已通过1实现,没问题
对于条件4:已通过1实现,没问题
四、另外
事实上,几乎所有的比较好的方案,都要求客户预先安装一个包,这个包提供了widget容器,UI解释器,以及强大事件和业务语言。因此我将上面这些方案和下面几种技术比较,
发现下面几种技术也有可取之处,这几种解决方案的思路都是一样的:widget容器我不提供,我提供一些解释不同widget的解释器,提供事件和业务语言。
python、ruby等的UI解决方案,通过一些对别的widget库的调用,来展现UI,UI的表现形式通常是DSL似的文本,另外通过语言本身提供业务和事件相应。这种解决方案和webstart类似。
按照上面我列出来的几个标准来看,我个人认为最好最成熟的就是flex(但我个人并没有FLEX方面的实际开发经验,有人说FLEX的组件太少,而且收费),其次是银光。
一个真正好的RIA,商业上的推广策略也是很重要的。因此银光也值得大家关注。
(Reprinted from : http://www.javaeye.com/topic/368377)