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表现层的一种应用方式呢？

 

三、组件化界面开发

目前有很多开发框架都突出表现层组件化处理的思想，流行的框架有Tapestry、Turbine、ECHO、JSF等，ECHO、JSF没有深入研究，不敢多说。

个人比较喜欢Tapestry，本来计划在工作流应用开发框架中，采用Tapestry做为主框架，后来因故没有继续，现在一直很关注这个项目。

Turbine，03年4月计划对Jetspeed进行改造，做一个支持拖拽、基于Web的门户配置工具，想的比较简单，结果发现这家伙是在Turbine基础之上的应用系统，分析了这两个系统后，还是放弃了原计划，就两个礼拜时间，进度要紧，只是简单的进行了汉化和样式改造，将用户认证部分和公司的产品进行了整合，做完后大家说怎么还不如上个版本的主界面，上个版本是项目组自己用JS和DHTML做的一个组件拖拽的界面配置工具，没有采用portlet标准，而且速度也比较慢，但是很漂亮。这件事让我们对Apache的印象也开始变坏了，呵呵。

但凡一项技术，如果有好的工具和丰富的资源库支撑，容易上手的话，那么它能很快使用和传播。

同样基于界面组件开发技术能否成功的关键，是组件库的丰富和设计工具的易用性，如果能有这样的产品出现，Web表现层的开发效率才能真正提高，JSF据说可提供可视化工具支持，而且Apache 的Jakarta项目组已做了很多JSF和Structs的集成工作，暂且看看吧，不知道什么时候能有好用的开发工具面世。

说起开发工具，让我想起一件事，那是01年的时候，我们承接了一个电子商务网站的开发，当时聘了一个项目经理，据说对Websphere Studio很熟，领导也要求用IBM的Websphere，他给我们演示了一个DB快速开发的例子，和PB的数据窗口类似，后来项目因故无法采用Websphere，这位PM没办法，只能和大家一样，用JSP编，最后的结果是代码质量最差的就是他，惨不忍睹。

题外话：
1、Struts

一直有同事问我：为什么不用Struts做应用开发框架？倒不是说它有什么不好，原因有2条：

很多地方它已经“陈旧”了，比如Filter和Dispatch，已经在Servlet2.3中形成了标准，成为Servlet容器支持的功能，如果是这样，Struts似乎应该进行修改以适应Servlet标准的变化。

表现层基于Taglib，延用公司现有的XML和XSL表现层实现方案需要进行改造，据说在和JSF集成，还是等发布了后再说吧。

现在经常和同事说，Apache的东西和它宣传的不一样，不能都信。Slide说它已经可以对文件进行版本控制，实际上没有实现，全文检索没有采用Lucene，当然它自己也没有实现这个功能，要用它必须自己改造；最可气的是Tomcat，4.0发布时说完全支持Servlet2.3标准，结果按照标准写出来的Filter和Dispatch程序，分开单独运行都正常，合在一起就无效，同样程序放在Weblogic上就没问题，到bug库里一查，还真有这个bug，一直拖了几个月都没有改，傲慢得不行，现在总算是好了，可是害得我们的当初的设计结构要做变更，好端端的程序明明是正确的，却不能用，把人气够呛。

2、微软和J2EE

微软做为PC系统软件的霸主，一直想进入由IBM、SUN这些公司把持的企业应用高端。而后者也想抢占PC平台地盘，双方都拿标准来压对方，各自推出的技术有些地方都很有趣。

后者通过定位论将微软死死摁在“低端”，从设计企业应用体系框架时就一心想绕开PC平台上的微软操作系统，将原来大家认为合理的服务器端进行数据处理，客户端进行表现处理的模式生生拉回到中央主机模式，但是B/S的致命缺陷是用户交互能力实在太弱，看看实在是绕不过去了，可是一直没有好的办法解决，都说微软的软件吃内存，可是看看IBM的，不必微软的少，客户也很理解，说JAVA开发的吗，就是吃内存！有时想这些公司怎么连个JSP的可视化开发工具都做不好？SUN对JAVA的贡献越来越少，除了一大堆可以学习“过度设计”的接口外。

微软则拼着命的想把一切东西，包括服务器端的软件都给Windows化，先是将各种功能往浏览器里塞，与Windows紧密集成，浏览器现在是一统天下了，OK，我在把这玩意给你淡化，把Longhorn操作系统当浏览器，用XAML来进行应用程序开发，没有什么B/S和C/S。

如果从企业快速应用开发角度上看，微软的开发工具所提供的功能确实很和程序员的口味，使用vb.net的Form控件进行Web应用开发，一个PB程序员能很快上手进行数据库开发，尽管他不是很明白体系结构，但很多时候这就够了。让他学习JAVA、Servlet、JDBC、模式，要他一切从底层做起，很多人都觉得干吗要用J2EE（现在所在公司里的程序员使用Delphi和PB做了这么多年的开发，没有快速开发工具让他们很难适应）？

02年底的时候我突然想干吗非要用DHTML、JS做这种东西，MSN大家用的挺好，大家没觉得不用B/S方式实现就很不好。毕竟我们不是在做网站，所有的表现都用网页是不是过了？

如果让我描述我心目中理想的架构，我想是这样的，微软的表现层技术，J2EE的服务端技术，通过XML格式数据进行交互，用不用浏览器不是关键。开发工具？希望Borland能实现。