对谈：WebWork vs. Struts

最新推荐文章于 2021-05-27 10:03:49 发布

原创最新推荐文章于 2021-05-27 10:03:49 发布 · 1.1w 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#webwork #struts #action #portlet #servlet

电子杂志第一期专栏收录该内容

10 篇文章

订阅专栏

本文以对话形式比较WebWork和Struts两种流行的web框架。指出Struts的ActionForm不好用、接口难看、测试麻烦等问题；而WebWork的action是普通JavaBean，通过拦截器实现基础设施功能，功能可做成插件。还提及Struts稳定受支持，WebWork易测试，也给出改造Struts的折中办法。

透明/编著

本文的内容来自各种渠道，有朋友非正式的讨论与邮件往来，也有网络上的各种资料，还有开发者们口耳相传的实践经验。为了方便读者，我不揣冒昧将它们整理成对话的形式，并借了两个虚构人物（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就有了其生存的土壤。当然这就扯得有点远了。