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）。通过更加严格的隔离机制，牵涉逻

辑处理的操作被强制转移到逻辑层。从而完全保证了层次之间的清晰性。

评论 (0) All

登陆 还没注册？