本文的内容来自各种渠道，有朋友非正式的讨论与邮件往来，也有网络上的各种资料，还有开发者们口耳相传的实践经验。为了方便读者，我不揣冒昧将它们整理成对话的形式，并借了两个虚构人物（WebWork的爱好者Weber和Struts的老用户Steven）之口来比较这两种流行的web框架，希望对读者的选择有所帮助。

　　Steven：嘿，Weber，你最近忙什么呢？

Weber：哦，我刚做了一个项目，用WebWork做的，感觉挺好。

Steven：WebWork吗？我知道它，它有什么好的？

Weber：好处可多了，比Struts强太多了。你用Struts那么久，难道就不觉得有什么不舒服的吗？

Steven：恩……确实有一些。比如说，Struts的ActionForm其实不太好用，有点不伦不类的，平白的在action和view之间引入了麻烦。Struts最近的设计也逐渐在淡化ActionForm的作用了。

Weber：是呀。而且Struts的不爽的地方还有接口比较难看。action必须要实现继承，到现在也没有改为接口继承。而且execute方法的接口也全是HttpServlet...，不能脱离servlet container，要测试还得提供mock的request，真是麻烦。

Steven：Struts由于要重用action的实例，因此不得不把所有状态从action里剔除，从而需要每次都传入request/response，这是一个典型的无状态设计，为pool和负载作了准备，理论上讲性能的延展性要更好一些。Struts由于每次都要处理request/response，所以必须提供一些工具方法，于是Action不再是接口，而改成一个class，这个设计在ood里也是常用的手法。如果没有这些接口，又怎么在servlet和action之间传递数据呢？

Weber：这就是WebWork的设计精彩之处了。action都是普通的JavaBean，它们只实现自己的业务功能，其他基础设施级的功能——例如怎么与servlet交换数据——都是用拦截器来实现的。正是因为有这个拦截器机制，所以WebWork才这么好用呢。

Steven：不过我看WebWork提供的功能还是比较少，比如它自己就没有数据校验的能力，必须要用别的工具来帮助校验。

Weber：没错，但这种功能都可以用拦截器机制来做，你可以把这些拦截器抽象出来复用。所以WebWork本身不需要包含那么齐全的功能，它只提供了一个灵活的核心，很多功能都可以做成插件插进去。而Struts就比较麻烦了，新加一个功能就会伤筋动骨，所以Struts老是有很多新特性要发布呢。

Steven：是的。最近Struts又放出消息，未来的版本将增加对JSR-168 portlet的支持。

Weber：这个问题在WebWork里根本就不成问题。只要做一个portlet作为引擎，再修改几个配置，所有的WebWork action都可以原封不动地移植到po

[1] [2] 下一页

在google里搜索更多对话：Web技术的思考

	Web www.51ec.org