特 征

Struts1.1

WebWork2

Action类

在Struts里面，每一个Action类必需要继承一个抽象的类org.apache.struts.action.Action。这个在Java编程中会引来一些问题，就是关于多种继承的问题。

WebWork的Action类仅需要实现接口com.opensymphony.xwork.Action，也可以实现其它的接口来实现更多的功能，譬如：validate（验证），localware(国际化)等。当然，它也提供了一个类ActionSupport集成了上面的所有功能，我们在开发中可以根据需要选择。

线程模型

Struts 的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了线程安全的问题。

在WebWork中，每个请求对应一个Action，因此没有线程的安全问题。实际上Servlet容器对每个请求也产生多个对象，它也没有证明对性能和垃圾回收产生太多的影响。

Servlet的依赖

Struts处理Action时必需要依赖ServletRequest 和ServletResponse，所有它摆脱不了Servlet容器。

WebWork的Action不用依赖Web层和其它的容器。它可以通过ActionContext，直接去访问Request和Response，但这个是可选的，只有在必需的请求下使用。

测试

Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试。

Webwork的action能够通过赋予一定的属性，就可以执行单元测试。同时也可以使用一个mock的实例去测试，而不是通过启动web容器来进行测试。

FormBean

Struts要求有FormBean对应每一个表单，而且FormBean必需继承抽象类ActionForm。而使用DynaBeans实际上没有太大的意义。不能够很好的处理现有的模型。

Webwork 能够动态的收集web的数据然后再赋值给bean。它也可以使用FormBean的形式，FormBean可以是普通的DTO和域对象，它不用重新根据域对象来生成新的FormBean，也不需继承抽象类ActionForm。

前端表达式语言

Struts集成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。

WebWork的表达式语言使用了功能强大的OGNL。它使用OGNL建立一个OgnlValueStack来搜索数据。Webwork前端也可以使用JSTL，但它同时支持：velocity、freemaker、jspparer、xml。

类型的转换

Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。

WebWork使用OGNL进行类型转化，提供了所有基本类型的转化功能。类型转化可以直接对一个Class进行（Class级别）转化，也可以对Class的字段进行类型转化。它使用拦截器可以很容易的将类型转化的错误信息返回给用户，而且错误信息可以对应到一个相应的字段。

对Action 执行前和后的处理

Struts处理Action的时候是基于class的hierarchies，很难在action处理前和后进行操作。

Webwork2 允许您处理Action可以通过拦截器，就是在每一个Action处理前或者后进行其它操作。它的拦截器可以在配置文件中动态添加，这样Action和拦截器之间完全解藕，更好的实现了组件化。

验证处理

Struts的验证是调用FormBean的validator()方法，其实就是对FormBean的验证。它一般使用框架Commons Validation进行数据验证处理。它使用了一个全局的配置文件validation.xml定义了FormBean的验证信息。Struts的FormBean属性都被认为是String类型，所以它在验证时也需要额外的类型转化。

WebWork使用Xwork的验证框架进行验证处理，它可以通过配置拦截器来激活。它可以为每个需要验证的Class指定一个xml验证文件，也可以为一个Class在不同的情况指定不同的xml验证文件。WebWork证可以给每个Action类指定对应的验证文件，也可以给Action的字段去指定验证文件。通过拦截器来组装Action和其验证文件，使它们之间完全解藕。

对Action执行的控制

Struts创建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重新去写Servlet来实现你的这个功能需求。

在这个方面，WebWork的拦截器栈提供了强大的功能。Action的所有切面功能都有拦截器来实现（比如：取得request请求参数、验证处理等），这样你就可以用拦截器栈来组织拦截器的执行顺序。例如：你需要在使用request请求参数来设置Action属性之前，使用IoC框架设置Action的属性，反之已然。这时，你就可以为package或Action指定一个拦截器栈来实现。

Feature

Struts

WebWork 1.x

WebWork 2.x

Action classes

Struts requires Action classes to extend an Abstract base class. This shows a common problem in Struts of programming to abstract classes instead of interfaces.

Action classes must implement the webwork.Action Interface. There are other Interfaces which can be implemented for other services, such as storing error messages, getting localized texts, etc. The ActionSupport class implements many of these Interfaces and can act as a base class. WebWork is all written to Interfaces, which allows for plugging in your own implementations.

An Action must implement the com.opensymphony.xwork.Action Interface, with a series of other Interfaces for other services, like in WebWork 1.x. WebWork2 has its own ActionSupport to implement these Interfaces.

Threading Model

Struts Actions must be thread-safe because there will only be one instance to handle all requests. This places restrictions on what can be done with Struts Actions as any resources held must be thread-safe or access to them must be synchronized.

WebWork Actions are instantiated for each request, so there are no thread-safety issues. In practice, Servlet containers generate many throw-away objects per request, and one more Object does not prove to be a problem for performance or garbage collection.

ditto

Servlet Dependency

Struts Actions have dependencies on Servlets because they get the ServletRequest and ServletResponse (not HttpServletRequest and HttpServletResponse, I've been told) when they are executed. This tie to Servlets (although not Http*) is a defacto tie to a Servlet container, which is an unneeded dependency. Servlets may be used outside a Web context, but it's not a good fit for JMS, for instance.

WebWork Actions are not tied to the web or any container. WebWork actions CAN choose to access the request and response from the ActionContext, but it is not required and should be done only when ABSOLUTELY neccessary to avoid tieing code to the Web.

ditto

Testability

Many strategies have sprung up around testing Struts applications, but the major hurdle is the fact that Struts Actions are so tightly tied to the web (receiving a Request and Response object). This often leads people to test Struts Actions inside a container, which is both slow and NOT UNIT TESTING. There is a Junit extension : Struts TestCase (http://strutstestcase.sourceforge.net/)

WebWork actions can be tested by instantiating your action, setting the properties, and executing them

ditto, but the emphasis on Inversion of Control makes testing even simpler, as you can just set a Mock implementation of your services into your Action for testing, instead of having to set up service registries or static singletons

FormBeans

Struts requires the use of FormBeans for every form, necessitating either a lot of extra classes or the use of DynaBeans, which are really just a workaround for the limitation of requiring FormBeans

WebWork 1.x allows you to have all of your properties directly accessible on your Action as regular Javabeans properties, including rich Object types which can have their own properties which can be accessed from the web page. WebWork also allows the FormBean pattern, as discussed in "WW1:Populate Form Bean and access its value"

WebWork 2 allows the same features as WebWork 1, but adds ModelDriven Actions, which allow you to have a rich Object type or domain object as your form bean, with its properties directly accessible to the web page, rather than accessing them as sub-properties of a property of the Action.

Expression Language

Struts 1.1 integrates with JSTL, so it uses the JSTL EL. This EL has basic object graph traversal, but relatively weak collection and indexed property support.

WebWork 1.x has its own Expression language which is built for accessing the ValueStack. Collection and indexed property support are basic but good. WebWork can also be made to work directly with JSTL using the Filter described in WW1:Using JSTL seamlessly with WebWork

WebWork 2 uses XW:Ognl which is a VERY powerful expression language, with additions for accessing the value stack. Ognl supports very powerful collection and indexed property support. Ognl also supports powerful features like projections (calling the same method on each member of a collection and building a new collection of the results), selections (filtering a collection with a selector expression to return a subset), list construction, and lambda expressions (simple functions which can be reused). Ognl also allows access to static methods, static fields, and constructors of classes. WebWork2 may also use JSTL as mentioned in WW1:Using JSTL seamlessly with WebWork

Binding values into views

Struts uses the standard JSP mechanism for binding objects into the page context for access, which tightly couples your view to the form beans being rendered

WebWork sets up a ValueStack which the WebWork taglibs access to dynamically find values very flexibly without tightly coupling your view to the types it is rendering. This allows you to reuse views across a range of types which have the same properties.

ditto

Type Conversion

Struts FormBeans properties are usually all Strings. Struts uses Commons-Beanutils for type conversion. Converters are per-class, and not configurable per instance. Getting a meaningful type conversion error out and displaying it to the user can be difficult.

WebWork 1.x uses PropertyEditors for type conversion. PropertyEditors are per type and not settable per Action, but field error messages are added to the field error map in the Action to be automatically displayed to the user with the field.

WebWork2 uses Ognl for type conversion with added converters provided for all basic types. Type converters default to these converters, but type conversion can be specified per field per class. Type conversion errors also have a default error message but can be set per field per class using the localization mechanism in WW2 and will be set into the field error messages of the Action.

Modular Before & After Processing

Class hierarchies of base Actions must be built up to do processing before and after delegating to the Action classes, which can lead deep class hierarchies and limitations due to the inability to have multiple inheritance WW:Comparison to Struts#1

Class hierarchies

WebWork 2 allows you to modularize before and after processing in Interceptors. Interceptors can be applied dynamically via the configuration without any coupling between the Action classes and the Interceptors.

Validation

Struts calls validate() on the FormBean. Struts users often use Commons Validation for validation. I don't know a lot about this, so I'll put some questions here:
 
Because FormBean properties are usually Strings, some types of validations must either be duplicated (checking type conversion) or cannot be done?
 
Can Commons Validation have different validation contexts for the same class? (I've been told yes, so that's a good thing)
 
Can Commons Validation chain to validations on sub-objects, using the validations defined for that object properties class?

WebWork1.x calls the validate() method on Actions, which can either do programmatic validations or call an outside validation framework (this is apparently the same as Struts)

WebWork2 can use the validate() method of WebWork and Struts and / or use the XW:Validation Framework, which is activated using an XWork Interceptor. The Xwork Validation Framework allows you to define validations in an XML format with default validations for a class and custom validations added for different validation contexts. The Xwork Validation Framework is enabled via an Interceptor and is therefore completely decoupled from your Action class. The Xwork Validation Framework also allows you to chain the validation process down into sub-properties using the VisitorFieldValidator which will use the validations defined for the properties class type and the validation context.

Control Of Action Execution

As far as I know Struts sets up the Action object for you, and you have very little control over the order of operations. To change them I think you need to write your own Servlet to handle dispatching as you want

The ActionFactory chain controls the order in which an Action is constructed and initialised, but this requires writing a class

The interceptor stacks in WebWork 2 are hugely powerful in this regard. All aspects of Action setup have been moved into Interceptor implementations (ie setting paramters from the web, validation etc), so you can control on a per action basis the order in which they are performed. For example you might want your IOC framework to setup the action before the parameters are set from the request or vice versa - you can thusly control this on a per package or per action basis with interceptor stacks.