传统的JSP技术为Web表现层技术提供了灵活、丰富的功能支持。然而，站在工程的角度
而言，过于凌乱的JSP Script也成为系统维护的头号大敌。
JSP 代码几乎等同于Java 代码，在提供了最丰富的特性支持的同时，也为系统的开发带
来一些隐患，程序员往往天马行空，不为羁束，在JSP 中将业务逻辑、数据逻辑、表现逻辑代
码相混杂，代码重用性、系统可维护性极低。特别是在参与开发人员众多，技术水平良莠不齐
的情况下，纵使技术经理一再强调设计规范的约束，但人本的约束总是难以控制，随着开发过
程进展和产品上线压力的增大，规范约束逐渐薄弱，于是难以避免的造成代码的混乱，可维护
性的下降。
面对这个问题，众多组织和厂商开始研发自己的表现层框架，试图通过一个隔离的表现层
框架，强行将表现层和逻辑层相剥离。时间似乎退回到了最初Web 端只支持Servlet 技术的
时代（那时候或多或少各个公司都有自己的模板实现）。不过，现在的模板技术经过长时间的
发展，已经将表现层的能力发挥得淋漓尽致，不失为JSP技术之外的一个明智选择。

模板技术相对传统JSP技术有以下三个主要优势：
1． 在技术层面，将表现逻辑与业务逻辑相分离。
2． 为人员之间的分工提供了一个良好的分界点。页面美工只需专著关心模板的设计，而程序员则专注于业务逻辑的实现。二者重合点明显减少。
3． 如果需要，模板引擎可脱离Web 容器单独运行，这为系统可能的移植需求提供了更多的弹性空间（这一特性在应用中也许并不会有太大的实际意义，只是提供了一种附加选择）。

目前Spring支持一下几种模板技术：
1． XSLT
XSLT是基于XML的表现层模板技术，伴随着XML的大量使用。XSLT也日渐成熟，并
迅速成为主流表现层技术之一。XSLT作为一个通用表现层框架，拥有最好的平台适应性，
几乎所有的主流程序设计语言都提供了XLST支持，现有的XLST模板可以简单的移植到不
同的语言平台，如将J2EE应用中的XSLT移植到.net平台，这样的可移植性是其他专用
模板技术，如Velocity和Freemarker难以达到的。
笔者在2001年在一个原型项目中采用了XSLT作为表现层实现，由于当时XSLT尚不
成熟，XSLT解析器效率低下，因此在正式产品开发中使用其他技术作为替代。在2003年
中，经过技术探讨，决定再次在项目实施中引入XSLT 技术，相对两年前，此时的XSLT
技术已经相当成熟，解析器的效率也大大改善。经过半年时间的项目研发，产品上线，并
取得了令人满意的表现。不过，在之后的项目回顾过程中，笔者认为，目前在项目中大量
采用XSLT技术尚不可取，上述项目开发过程中，XSLT技术提供了极佳的扩展性和重用性，
也保证了业务逻辑和表示逻辑的清晰划分，然而，最大的问题是，XSLT缺乏强有力的编辑
器支持。虽然通过XML/XSLT 技术成全了设计上近乎完美的表现，但却为界面开发带来了
极大难度，以至后期复杂界面的修改都需要消耗极大的人力，得不偿失。
笔者在项目开发中所用的XSLT 编辑器为StylusStudio 和XmlSpy，目前这两款编
辑器可以算是XSLT开发的首选，提供了丰富的特性和可视化编辑功能。但即便如此，XLST
繁杂苛刻的语法和调试上的难度也为开发工作带来了极大的障碍。
此外，也许是最重要的一点，xslt在性能上的表现尚不尽如人意。经过多年的发展，
XSLT解析/合成器的性能相对最初已经大为改观，但依然与其他模板技术存在着较大差距。
据实地测试，FreeMarker和Velocity对于同等复杂度的表现层逻辑，平均处理速度是
XSLT 的10 倍以上，这是一个不得不正视的性能沟壑。同时，XSLT 的内存占用也是
FreeMarker 和Velocity 的数倍有余（XSLT 中，每个节点都是一个Java 对象，大量
对象的存储对内存占用极大，同时大量对象的频繁创建和销毁也对JVM 垃圾收集产生了较
大负面影响）。在上述项目中，由于硬件上的充分冗余（8G RAM, 4CPU），才使得这些
性能上的影响相对微弱。
因此，目前在项目中大量引入XSLT技术尚需仔细考量。
2． Velocity
Velocity是Apache Jakarta项目中的一个子项目，它提供了丰富强大的模板功能。
作为目前最为成熟的模板支持实现，Velocity 在诸多项目中得到了广泛应用，不仅
限于Web 开发，在众多代码生成系统中，我们也可以看到Velocity 的身影（如
Hibernate中的代码生成工具）。
3． FreeMarker
FreeMarker是Velocity之外的另一个模板组件。
与Velocity 相比，FreeMarker 对表现逻辑和业务逻辑的划分更为严格，
Freemarker在模板中不允许对Servlet API进行直接操作（而Velocity可以），
如FreeMarker 中禁止对HttpServletRequest 对象直接访问（但可以访问
HttpServletRequest对象中的Attribute）。通过更加严格的隔离机制，牵涉逻
辑处理的操作被强制转移到逻辑层。从而完全保证了层次之间的清晰性。
另外一个Velocity无法实现的特性，也是最具备实际意义的特性：FreeMarker对
JSP Tag提供了良好支持。这一点可能存在一点争议，JSP技术的最大问题就是容易
在页面中混入逻辑代码。而FreeMarker 对JSP Tag 的支持似乎为这个问题又打开
了大门。这一点上，我们可以将FreeMarker看作是仅允许使用TAG的JSP页面（实
际上，FreeMarker的表达式语法与EL语法也非常类似）。
从开发角度而言，只允许使用TAG的JSP页面，已经在很大程度上保证了页面表现逻
辑与业务逻辑的分离。程序员在JSP Script中混杂逻辑代码的原因，大部分是出于
慵懒，只要无法在页面模板中直接编写Java代码，相信程序员也不会去专门编写一个
JSP TAG来刻意违反层次划分原则。
对JSP TAG 的支持为FreeMarker 带来了极大的活力，目前开源社区中已经有了为
数众多的成熟Taglib，如DisplayTag、Struts Menu等，这些功能丰富，成熟可
靠的Taglib，将为产品开发提供极大的便利。另一方面，这也为代码重用提供了另一
个可选途径，避免了大部分模板实现在这一点上的不足。
就笔者的经验，对于Web开发而言，FreeMarker在生产效率和学习成本上更具优势，
而Velocity 的相对优势在于更多第三方工具的支持和更广泛的开发和用户团体（然
而对于一个轻量级模板类库而言，这样的优势并不是十分明显）。
如果没有Velocity的技术储备，而又需要通过技术上的限定解决视图/模型的划分问
题，这里推荐采用FreeMarker作为Spring MVC中的表现层实现。以获得最好的（学
习、开发）成本受益。