UI展现技术总结

我个人工作中有过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，商业上的推广策略也是很重要的。因此银光也值得大家关注。