下班前，给Jameson, Mike, Jarod一起做了一个关于Webwork+FreeMarker框架的简单培训。通过给他们讲这些不同的技术框架，也让我有了心思将一些流行的框架进行以下分析和对比。
我们开发爱逛网（http://www.i-guang.com）用的是Struts，个人始终对这个Struts有点“偏见”，从Struts开始出来的时候就没有太多兴趣，觉得它虽然也比较好的实现了MVC，可总是显的不够优雅，每个Input页面都得一个FormBean，再需要一个基本相同代码的ModelObject，而且这种View--Action的模式也相对来讲不是很适合大规模的开发。
虽然Webwork与Struts基本上可以归为同一类的Web Framework，但是与Struts相比，Webwork要显的优雅很多。通过引入Interceptor的AOP机制，使的模块之间的耦合程度大大降低，而且View到ModelObject的映射实现方式OGNL（Object Graph Notation Language）也相对比较自然。另外，在Action的执行前后，也可以实现比Struts的Action更多的控制。当然，action chain更是Struts中没有的。
Velocity、FreeMarker这些并不能算是一个完整的Web框架，只能算是一个Web框架中所使用到的工具。
相比以上这些，我个人更看好JavaServer Faces，抛开JSF是标准而非一个简单的open source framework，个人认为，JSF将是未来发展的主流，因为软件开发“工业化”不可避免的是未来发展的方向。
JSF的主张是用Delphi的组件思想来开发Web应用程序。这个说起来容易，做起来很难。Web应用程序因为是基于Http等无状态协议的，不像C/S程序一样是实时连接（大部分是这样），服务器端很难维护客户端的状态。这也就是为什么Web应用可以比C/S程序拥有更多的并发访问用户的原因。
要实现这个“类C/S”开发，首先就需要对Web开发的琐碎细节进行抽象封装，将Web协议，各种细节技术隐藏，以一个可公用的组件去展现，这个确实是一个不小的工程。
JSF与Webwork/Struts等另一个很大的不同是:JSF没有用View-action机制，而是用了View-Backing Bean的机制，看上去一样，可原理却大不相同。Webwork/Struts中的action都是用了一种设计模式，比如command模式，让这些Action继承一个抽象类来实现某个特定的方法，用来处理页面输入。而JSF的Backing Bean确是充分利用了Java Bean的优点：简单，反射，灵活，IOC，没有用任何特别的设计模式，不需要继承或实现什么抽象类或接口，只需要一个简单的Bean（需要配置为Managed Bean，让容器来管理），而对页面中Form的submit action也可灵活的指定为Backing Bean中的任意一个方法。
此外，JSF还充分利用了Swing编程中的Event机制，通过EventListener实现无页面跳转的事件响应，而这个在Struts中实现起来是相对困难的。
从宏观层面上看，JSF具有其他框架所不具备的意义，那就是JSF更关注开发人员的分工，通过封装降低对开发人员的技能需求（比如页面开发人员对JavaScript技能的需求），实现了业务逻辑的组件封装重用....而这些，正是软件开发“流水线化”、“工业化”的必要条件。
虽然，开发自己的组件需要充分理解JSF的原理、底层细节，但是这只是一个小问题，而且一个框架的发展从来都是不断降低门坎的过程。
相信JSF会有一个灿烂的未来。
这次比较没有比较Spring，因为我觉得Spring与这些Web框架不是一类，基本不具备什么可比性。Spring更像一个可“海纳百川”的大框架，通过简单的IoC和AOP思想来实现不同模块之间的松散耦合，并且可以通过IoC来整合大部分Web Framework（关于IoC，请参见我的另外一片文章《理解IoC》。而且，Spring不单单可用于Web应用，其他应用同样可以使用Spring框架，可使用其AOP/Application Context/JDBC, ORM等部分。而，Spring与JSF很类似的一点就是：两者都充分使用了Java Bean技术。Spring中的BeanFactory，JSF中的Backing Bean。