本文的内容来自各种渠道，有朋友非正式的讨论与邮件往来，也有网络上的各种资料，还有开发者们口耳相传的实践经验。为了方便读者，我不揣冒昧将它们整理成对话的形式，并借了两个虚构人物（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都可以原封不动地移植到portlet环境，因为它们原本就是最普通的JavaBean，根本就不知道外面的环境究竟是servlet环境还是portlet环境。由于action不依赖具体的运行环境，所以单元测试也很方便，直接把action new出来，把参数设置进去就可以测试了。

Steven：说起测试嘛，抛开先富起来的地区不说，起码中国还有1/3的软件企业处在对TDD懵懂的阶段吧？还有1/3的企业在追捧CMM和一些瀑布模型的开发方法吧？那么对于这些企业，Struts和WebWork在易测上的差异他们是感受不到的。当前的状态下，易测性并不是软件企业技术选型的一个重点目标，那么Struts就有了其生存的土壤。当然这就扯得有点远了。

Weber：你说得很有道理。Struts好在够多的人支持、使用，让人觉得够稳定、保险、有保障。要是做个项目，很多老板一定说，我要的不是新技术，要的是稳定。所以我现在也还常常在用Struts开发项目。

Steven：看来我也应该多了解一下WebWork。如果以后采用TDD的开发方法，可测性的确是很重要的因素，那时也许我就会选择用WebWork了。

Weber：还有一种折中的办法，就是改造Struts，给它加上拦截器机制，然后再用拦截器来实现Dependency Injection，这样可以把Struts变得跟WebWork一样易用，而且又不会损失它原来的功能，实现起来也不算复杂。

Steven：确实不错。这么一来，我的工具箱里又多了一种可选的方案了。

附录：关于Struts与WebWork之间的技术比较，请看下列两个地址：http://udoo.51.net/mt/archives/000044.html，http://wiki.opensymphony.com/display/WW/Comparison+to+Struts