Struts1 requires Action classes to inherit an abstract base class. A common problem with Struts1 is programming with abstract classes instead of interfaces.
• The Struts 2 Action class can implement an Action interface or other interfaces, making optional and customized services possible. Struts2 provides an ActionSupport base class to implement commonly used interfaces. The Action interface is not required. Any POJO object with the execute identifier can be used as the Action object of Struts2.
Thread mode:
• Struts1 Action is a singleton mode and must be thread-safe, because only one instance of Action handles all requests. The singleton strategy limits what Struts1 Action can do, and special care must be taken during development. Action resources must be thread-safe or synchronized.
• The Struts2 Action object generates an instance for each request, so there are no thread safety issues. (In fact, the servlet container generates many discardable objects per request and does not cause performance and LJ recycling problems)
Servlet dependencies:
• Struts1 Action relies on the Servlet API because HttpServletRequest and HttpServletResponse are passed to the execute method when an Action is called.
• Struts 2 Action does not depend on the container, allowing the Action to be tested independently of the container. Struts2 Action can still access the original request and response if needed. However, other elements reduce or eliminate the need to access HttpServetRequest and HttpServletResponse directly.
Testability:
• A major problem with testing Struts 1 Actions is that the execute method exposes the servlet API (which makes testing dependent on the container). A third-party extension - Struts TestCase - provides a set of Struts1 mock objects (for testing).
Struts 2 Action can be tested by initializing, setting properties, and calling methods. "Dependency injection" support also makes testing easier.
Capture input:
• Struts1 uses ActionForm objects to capture input. All ActionForms must inherit a base class. Because other JavaBeans cannot be used as ActionForms, developers often create redundant classes to capture input. Dynamic Beans (DynaBeans) can be used as an alternative to creating traditional ActionForms. However, developers may be re-describing (creating) existing JavaBeans (still resulting in redundant javabeans).
• Struts 2 uses Action properties directly as input properties, eliminating the need for a second input object. Input properties may be rich object types with their own (sub) properties. Action properties can be accessed through taglibs on the web page. Struts2 also supports ActionForm mode. Rich object types, including business objects, can be used as input/output objects. This ModelDriven feature simplifies taglib's reference to POJO input objects.
Expression language:
• Struts1 integrates JSTL and therefore uses JSTL EL. This EL has basic object graph traversal, but support for collections and indexed properties is weak.
• Struts2 can use JSTL, but also supports a more powerful and flexible expression language - "Object Graph Notation Language" (OGNL).
Bind the value to the page (view):
• Struts 1 uses standard JSP mechanisms to bind objects to pages for access.
Struts 2 uses "ValueStack" technology to enable taglib to access values without binding your page (view) to the object. The ValueStack strategy allows reuse of pages (views) through a series of properties with the same name but different types.
Type conversion:
• Struts 1 ActionForm properties are usually of type String. Struts1 uses Commons-Beanutils for type conversion. One converter per class, not configurable per instance.
• Struts2 uses OGNL for type conversion. Provides converters for basic and commonly used objects.
check:
• Struts 1 supports manual verification in the validate method of ActionForm, or verification through the extension of Commons Validator. The same class can have different verification contents, but sub-objects cannot be verified.
• Struts2 supports verification through the validate method and the XWork verification framework. The XWork validation framework uses the validation and content validation defined for the attribute class type to support the chain validation sub-property.
Action execution control:
• Struts1 supports separate Request Processors (life cycle) for each module, but all Actions in the module must share the same life cycle.
• Struts2 supports creating different life cycles for each Action through Interceptor Stacks. Stacks can be used with different Actions as needed
This article comes from the CSDN blog. Please indicate the source when reprinting: http://blog.csdn.net/Ryan_lz/archive/2009/12/29/5101758.aspx