Struts1 与 Struts2 的比较

Action classes |	Struts 1 requires Action classes to extend an abstract base class. A common problem in Struts 1 is programming to abstract classes instead of interfaces.	An Struts 2 Action may implement an Action interface, along with(连同) other interfaces to enable optional and custom services. Struts 2 provides a base ActionSupport class to implement commonly used interfaces. Albeit(尽管), the Action interface is not required. Any POJO object with a execute signature(签名) can be used as an Struts 2 Action object.
Threading Model |	Struts 1 Actions are singletons(单例)and must be thread-safe since there will only be one instance of a class to handle all requests for that Action. The singleton(单例) strategy(策略) places restrictions(限制) on what can be done with Struts 1 Actions and requires extra(额外) care(小心) to develop. Action resources must be thread-safe or synchronized.	Struts 2 Action objects 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 impose a performance penalty or impact garbage collection.)
Servlet Dependency |	Struts 1 Actions have dependencies(依赖性)  on the servlet API since the HttpServletRequest and HttpServletResponse is passed to the execute method when an Action is invoked.	Struts 2 Actions are not coupled to a container. Most often the servlet contexts are represented(描述) as simple Maps, allowing Actions to be tested in isolation(隔离). Struts 2 Actions can still access the original(原始的) request and response, if required. However, other architectural elements reduce(减少) or eliminate(排除) the need to access the HttpServetRequest or HttpServletResponse directly.
Testability |	A major(主要的) hurdle(障碍) to testing Struts 1 Actions is that the execute method exposes(暴露) the Servlet API. A third-party(第三方) extension(扩展), Struts TestCase, offers a set of）(一套) mock object(模拟对象) for Struts 1.	Struts 2 Actions can be tested by instantiating the Action, setting properties, and invoking methods. Dependency Injection(依赖注入) support also makes testing simpler.
Harvesting Input |	Struts 1 uses an ActionForm object to capture(捕获) input. Like Actions, all ActionForms must extend a base class. Since  other JavaBeans cannot be used as ActionForms, developers often create redundant(多余的) classes to capture(捕获) input. DynaBeans can used as an alternative(替换物) to creating conventional(常规的) ActionForm classes, but, here too, developers may be redescribing existing JavaBeans.	Struts 2 uses Action properties as input properties, eliminating(消除) the need for a second input object. Input properties may be rich(丰富的) object types which may have their own properties. The Action properties can be accessed from the web page via(通过) the taglibs. Struts 2 also supports the ActionForm pattern, as well as POJO form objects and POJO Actions. Rich(丰富的) object types, including business(商业) or domain(领域) objects, can be used as input/output objects. The ModelDriven feature simplifies(简化) taglb references to POJO input objects.
Expression Language |	Struts 1 integrates(结合) with JSTL, so it uses the JSTL EL. The EL has basic object graph(图标) traversal(遍历), but relatively(相对的) weak(弱) collection and indexed property support.	Struts 2 can use JSTL, but the framework also supports a more powerful and flexible expression language called "Object Graph Notation Language" (OGNL).
Binding values into views |	Struts 1 uses the standard(标准的) JSP mechanism(机制) for binding objects into the page context for access(存取).	Struts 2 uses a "ValueStack" technology(技术) so that the taglibs can access values without coupling(耦合) your view to the object type it is rendering. The ValueStack strategy(策略) allows reuse of views across(穿过) a range of(一些) types which may have the same property name but different property types.
Type Conversion |	Struts 1 ActionForm properties are usually all Strings. Struts 1 uses Commons-Beanutils for type conversion. Converters are per-class, and not configurable per instance.	Struts 2 uses OGNL for type conversion. The framework includes converters for basic and common object types and primitives(基本).
Validation |	Struts 1 supports manual(手册) validation(校验) via(通过) a validate method on the ActionForm, or through an extension to the Commons Validator. Classes can have different validation contexts for the same class, but cannot chain to validations on sub-objects.	Struts 2 supports manual validation via the validate method and the XWork Validation framework. The Xwork Validation Framework supports chaining validation into sub-properties using the validations defined for the properties class type and the validation context.
Control Of Action Execution	Struts 1 supports separate(单独的) Request Processors (lifecycles(生命周期)) for each module(模块), but all the Actions in the module must share the same lifecycle.	Struts 2 supports creating different lifecycles on a per Action basis via Interceptor Stacks. Custom stacks can be created and used with different Actions, as needed.

 

 

 

 

以上为本人试练翻译，以下为转自前辈的中文翻译(http://ikingqu.iteye.com/blog/68597)

 

 

Action 类: 
• Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。 
• Struts 2 Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去 实现 常用的接口。Action接口不是必须的，任何有execute标识的POJO对象都可以用作Struts2的Action对象。 

线程模式: 
• Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。 
• Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题） 

Servlet 依赖: 
• Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。 
• Struts 2 Action不依赖于容器，允许Action脱离容器单独被测试。如果需要，Struts2 Action仍然可以访问初始的request和response。但是，其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。 

可测性: 
• 测试Struts1 Action的一个主要问题是execute方法暴露了servlet API（这使得测试要依赖于容器）。一个第三方扩展－－Struts TestCase－－提供了一套Struts1的模拟对象（来进行测试）。 
• Struts 2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使测试更容易。 

捕获输入: 
• Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经 常创建多余的类捕获输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述(创建)已经存 在的JavaBean（仍然会导致有冗余的javabean）。 
• Struts 2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过 web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型，包括业务对象，能够用作输入/输出对象。这种 ModelDriven 特性简化了taglib对POJO输入对象的引用。 

表达式语言： 
• Struts1 整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。 
• Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object Graph Notation Language" (OGNL). 

绑定值到页面（view）: 
• Struts 1使用标准JSP机制把对象绑定到页面中来访问。 
• Struts 2 使用 "ValueStack"技术，使taglib能够访问值而不需要把你的页面（view）和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面（view）。 

类型转换： 
• Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器，对每一个实例来说是不可配置的。 
• Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。 

校验： 
• Struts 1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容，但不能校验子对象。 
• Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验，来支持chain校验子属性 

Action执行的控制： 
• Struts1支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期。 
• Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。