Web表现层开发的思考（一）

Web表现层开发的思考（一）

web的表现层一直是体现各个框架个性的地方，流派繁杂，秘技叠出，乱花渐欲迷人眼，在做开发过程和技术架构定义时，我们往往最头疼的就是表现层的设计，设计的原则是什么？如何根据项目特点决定开发过程，以及决定采用哪种表现层框架。

Thin和Rich客户端和早期的基于主机和C/S分布式应用开发模式的思想是类似的，只不过将Client程序变成了浏览器。个人认为Thin客户端比较适合做站点应用或者企业应用中界面和功能比较简单的查询和数据填报工作，而Rich客户端比较适合做企业应用软件。

还是根据实际在项目开发过程的一些体会来对Web的表现层开发技术来进行探讨吧。

一、Thin Client：

01年以前，我将Web开发分为下面几个流派：
1、 ASP、PHP、JSP，即HTML类表现代码嵌入业务处理代码的程序语言，主体是页面代码＋动态程序逻辑，Taglib、JavaBean技术基本上可以归入到此流派；
2、 CGI、Servlet，即动态程序逻辑＋页面代码处理；目前绝大部分的框架都是基于这种模式的基础上展开；
3、 插件，即采用ActiveX、Applet进行业务逻辑和特殊表现处理；

（划分的方式不一定很周密，呵呵。）

第三种方式，对于java的界面编程，我有一种恐惧感，：），一直不敢尝试，有机会还是请这方面的高手谈更好。

第一种方式和第二种方式在Thin Client模式下采用的原则，我想可能还是看页面人员的能力和对页面变更频次来决定采用何种方式，如果是站点类的应用开发，采用第二种方式要好的多：
l 站点应用对美工的专业化要求较高，让美工去了解编程是很困难的，如果做过大型网站的同仁会有同感。
l 用户则对页面的个性化要求也很高，用户的页面经常发生变更，很难让用户一次就把界面锁定，模板的变更控制以及和开发的同步都是大伤脑筋的事情，相对于前台页面，后台业务变更的频次要小得多。
l 后期维护，如果采用第一种方式，往往用户在后期要求进行界面变更维护要求，或者要求增加多套模板，动用程序员去做这事，对公司而言无疑是加大成本的事情。如果模板的某一项发生变更，界面和程序员都会痛苦万分。
在这种情况下，表现层的技术设计应便于前后台的协同开发，便于实施和维护。

最早我们做的表现层，是采用模板加标签的思路，还是dlee做的（当时可是很牛哟），将页面模板打上标签，定义了变量、常量替换、循环处理等几个标签，标签语法用的是HTML的注释语法，基本上可以做到页面和程序分离，当时程序员用perl做页面输出是很痛苦的，页面一点都不懂编程，能做到这种状况，大家都还满意。

后来我们想用XML和XSL来做开发，dlee分析了cocoon后的意见是没有好的可视化工具来进行XSL编写，以后的经历证明当时没有贸然采用XSL是正确的,这些都是2000年的事了(01年初dlee离开公司去了德国)。

从网站项目到以后的网站产品的开发，对表现层的设计思路始终是基于模板技术，设计原则是模板上不能包含任何程序代码，很偏执的原则，呵呵。

基于这种思路，Apache项目组的很多框架的表现层实现技术被我们认为是不合适的，包括Turbine、Velocity等，还有JSP的Taglib技术，也被pass掉了，我们还是倾向于使用“干净”的页面模板，而不是嵌入代码的页面模板。从公司的角度上看，喜欢实用简单的框架，而不能学习成本过高，这也是放弃一些框架的原因。

模板处理的模式，具体的实现可以有很多种方式，比如：
将业务处理返回的数据进行XML封装，将标签用xsl标准进行定义，以注释方式写在页面上，通过引擎将两者绑定输出；当然也可以考虑将模板文件预先编译成xsl文件，然后两者绑定输出。

采用模板技术，由于每次表现层的处理都需要通过文件调用方法读取磁盘文件，IO操作会频繁，改进的思路是将模板对象化，具体的设计思想可以参考Enhydra，在此就不展开了。

对于Thin Client的表现层技术，我的体会是没有特别好的轻量级模板框架和发布引擎，包括Apache项目组的框架，各做各的，基于：模板、标签库、自定义标签、XML等各种思路，五花八门，看着都头疼。

二、Rich Client：

采用Rich Client表现层技术，我想在企业应用系统开发下使用会更合适。

企业应用系统的表现层有以下特点：
l 用户界面使用习惯，用户习惯于C/S模式的应用程序界面，习惯Windows的GUI风格，如果出现页面的刷新、跳转之类的会很不满意；
l 浏览器固定为IE，这意味着不必考虑其它的浏览器软件，技术上可以锁定MS的浏览器技术；
l 带宽高，做网站的禁忌很多不用考虑，比如对于Javascript，如果是网站，需要考虑流量要求；
l 与桌面和办公软件如OFFICE的集成度高；

1、IE做为Client端

由于只谈表现层，对于MVC的其它部分，假设是这种简化的架构：Model层返回VO，Controller层将VO调用相应的util程序进行XML数据封装。

Server端请求处理后返回的数据，可以按照SOAP的格式，进行消息、异常等定义，这样可以将Server与客户端彻底独立。

基于上述特点，我们需要重新考虑系统的架构，将与界面表现相关的逻辑处理全部放在前端，前台已经不是模板制作，而是客户端程序开发，需要理解业务逻辑，只不过采用的是JS。

结构上将MVC进行边界扩大，客户端也采用MVC方式，每个界面程序由主控JS做为Controller，加载页面的组件对象、事件处理等，每个组件对象通过XMLHTTP与Server端交互，界面上组件之间的关系处理也通过JS来进行，组件对象的表现通过XSL、HTC和JS实现与Windows GUI类似的功能。

由于是使用XMLHTTP来进行前台程序开发，对于前台程序开发人员来说，需要学习MS的很多技术，并且要把界面XSL化，加上大量的JS代码，工作量很大。

采用这种方式，尽管能让用户感觉到界面操作与C/S应用程序类似，但毕竟还有差异，同时客户端程序是在服务器端加载运行，速度上还是显得慢。

2、其它应用做为Client端

目前我们有个项目，客户要求用Delphi开发客户端（用Java开发的客户端应用程序，因为性能、外观、开发难度等等理由被客户给否掉了），后台服务必须用J2EE，不知道这算不算Rich Client表现层的一种应用方式呢？

顶一下。
不错。
这是我也在考虑的问题。
希望在web开发上有经验的同仁发表看法，交流提高。

to 一蓑烟雨任平生：
是啊，那是很多年前了，当时我还是一个技术激进分子，对新技术有着狂热的爱好。如果不需要做项目工资照发，我肯定一行代码也不给公司写。看看书、研究研究开源软件、写些文章浪得虚名。现在看来没有全力投入 Struts、MVC、XSLT、Cocoon、XSP 这些看上去很美的东西还是正确的。
我们现在前台的开发已经完全甩开了 Form 和 JSP，完全基于 XMLHTTP 了，详情请看以前我写的《基于 XMLHTTP 实现表示层的设计思路》。不过我们只用了 IE 和 Mozilla 都支持的功能（包括 XMLHTTP、XML DOM），没有用只有 IE 可以提供的功能。我的朋友 ly 是关于这方面思考最为深入的人。

现在论坛回信好象有点问题，只看到一个空白页面，不知道你是否收到。有空了来上海和我联系。
手机：13162001367，MSN：unruly_wind@sina.com

我认为
新一代的rich client解决方案很快出台

我比较看好
1 flash的延伸版本
2 新的marklanguage