基于 Java 的网站开发，很多人都采用 JSP 作为前端网页制作的技术，尤其在是国内。这
种技术通常有一些问题，我试想一下我们是怎样开发网站的，通常有几种方法
1：功能确定后，由美工设计网页的UI（界面）部分，然后由程序员在其上加入代码显示逻
辑（比如循环，判断显示数据结果）。也就是通常的 jsp 页面制作，当然这部分可以由美工
完成模板，然后由 jsp 工程师再继续以它为原型创建相应的 jsp 页面。
2：功能确定后，由美工设计网页的UI（界面）部分，然后由网页制作人员在其上加入代码
显示逻辑（比如循环，判断显示数据结果），在这一步的 jsp 页面制作中，网页制作人员（通
常只懂得 javascript 和 html ）在工程师的指导下学会如何嵌入 jsp taglib 标记，然后以美
工的模板为原型制作 jsp 网页。
显然后面一种方式要比前面一种方式分工明确，然后在很多小公司，或者项目很急的情况下。
jsp 网页制作和后台程序开发都是同一个人。这样无疑加大了程序员的负担。 后一种情况
虽然比前面的好，但是它有两个缺点： 一：网页制作人员必须学会如何使用 jsp taglib 的
使用，这无疑加大了网页制作人员的负担。二：如果页面因为客户的要求从新设计，那么无
论那种情况网页制作人员都要从新将显示逻辑从新嵌入 jsp 网页。
在这方面， jsp 做的并不好，虽然从性能角度和 taglib 的使用上来说，它比 php 和 asp 要
强很多， 但是它在设计上很类似 php 这种服务器页面语言，也就是在页面中嵌入脚本语言
的技术，虽然它比传统的基于 CGI 的脚本语言的开发模式速度快，但是它将后台程序逻辑
与页面显示混淆了，所以从这个角度来说, 它是一种不太良好的设计。想想看，你看到的众
多 php 程序是怎么样子的吧，在一堆 .php 文件中，你已经分不清楚那些是后台程序，那
些只是用来显示页面的程序。
现在更多的网站制作采用一种 MVC 模式，也就是将网站制作工作分工，分别为M(Model,
模型)，V（View 视图），C(Controller 控制器).
M(Model, 模型）也就是后台的事务逻辑，真正处理事务的代码，商业逻辑等等。他们是整
个网站最重要的工作部分，通常这部分代码相对来说比较稳定，不经常变动，就是有所变动
也不会对前端的页面有什么影响。
V（View 视图）: 也就是网页的显示部分，这个部分接受来自后台程序的结果或数据，进
行显示，但是这个部分通常是变化比较大的部分，比如网站的界面更新是经常要要作的事情，
每隔一段时间更新网页风格就会造成 View 视图部分的大量更改工作。
C(Controller 控制器). 在视图和模型之间传递控制，并根据要求调用相应的视图显示模型返
回的数据，主要负责调度工作。
这种职责的分工到底有什么好处呢，它简化了软件开发过程中所有相关人员的工作， 使得
不同的部分的修改通常不会影响的其他部分的工作，比如，我修改了后台某些程序的算法，
并不影响前台的页面显示，前台页面修改不影响后台程序的开发。这种分工合作比起 jsp 混
淆代码逻辑和显示层的做法要好的多。
所以越来越多的国外程序员在不断提出替代 jsp 的方案，在众多方案中， 一种基于 java 模
板引擎的技术脱颖而出，最为着名的是 Velocity 和 Webmacro 两种模板技术。
模板引擎的设计思想最早是有 webmacro 提出的， 后来应用在一个着名的搜索引擎
www.altavista.com 上， 这种思想渐渐被 Apache 开发小组所采用，并作为一个子项目被提
出来，这就是现在的 Velocity。模板引擎与MVC中视图这一部分的关系更为密切。它是经
常作为一种 jsp 的替代技术出现在国外的一些论坛上的。但是 Velocity 可以应用在任何需
要格式化数据显示的 java 程序中。
那么 Velocity 到底是什么呢？它的官方解释是：
"Velocity 是一种基于 java 的模板引擎，它允许任何人使用简单而强大的模板语言来引用定
