南顺网络

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离开公司去了德国)。 

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

编辑:--ns868