Comparison between Struts1 and Struts2

Comparison between Struts2 and Struts1 1. In terms of the Action Implementation class, Struts1 requires the Action class to inherit an abstract base class. A specific problem of Struts1 is the use of abstract class programming rather than interfaces. The Struts2 Action class can implement an Action interface or other interfaces to make optional and customized services possible. Struts2 provides an ActionSupport base class to implement common interfaces. Even if the Action interface is not required, only one POJO class containing the execute method can be used as the Action of Struts2. 2. thread mode: Struts1 Action is a singleton mode and must be thread-safe, because only one instance of Action can process all requests. The Singleton policy limits what Struts1 actions can do, and you need to be especially careful during development. Action resources must be thread-safe or synchronous. The Struts2 Action object generates an instance for each request, so there is no thread security problem. 3. Servlet dependency: The Struts1 Action depends on the Servlet API, because the execute method of the Struts1 Action includes the HttpServletRequest and HttpServletResponse methods. Struts2 Action no longer depends on the ServletAPI, allowing the Action to run out of the Web Container, thus reducing the difficulty of testing the Action. Of course, if Action needs to directly access the HttpServletRequest and HttpServletResponse parameters, Struts2 Action can still access them. However, most of the time, actions do not need to directly access HttpServletRequest and HttpServletResponse, thus giving developers more flexible choices. 4. testability: a major problem in testing Struts1 Action is that the execute method depends on Servlet on ServletAPI, which makes the test of Action still dependent on Web containers. To remove the Struts1 test Action from the Web Container, you must use a third-party Extension: Struts TestCase. This extension contains a series of Mock objects and thus disconnects the Web Container test Struts1 Action class. Struts2Action can be tested by initializing, setting properties, and calling methods. 5. encapsulation of request parameters: Struts1 uses the ActionForm object to encapsulate the user's request parameters. All actionforms must inherit a base class: ActionForm. Normal JavaBean cannot be used as an ActionForm. Therefore, developers must create a large number of ActionForm classes to encapsulate user request parameters. Although Struts1 provides dynamic ActionForm to simplify the development of ActionForm, it still needs to define ActionForm in the configuration file; Struts2 uses the Action attribute directly to encapsulate the user request attribute, this avoids the hassle of developers developing a large number of ActionForm classes. In fact, these attributes can also be Rich object types that contain sub-attributes. If developers still miss the Struts1 ActionForm mode, Struts 2 provides the ModelDriven mode, allowing developers to use separate Model objects to encapsulate user request parameters, however, this Model object does not need to inherit any Struts2 base class and is a POJO, which reduces code pollution. 6. Expression Language: Struts1 integrates JSTL, so JSTL can be used. This expression language provides basic object graph traversal, but does not support set and index attributes. Struts2 can use JSTL, however, it integrates a more powerful and flexible Expression Language: OGNL (Object Graph Notation Language). Therefore, the expression Language function in Struts2 is more powerful. 7. Bind the value to the view: Struts1 binds the object to the view page using the standard JSP mechanism; Struts2 uses the "ValueStack" technology to enable the tag to access the value, you do not need to bind the object with the view page. 8. type conversion: the attributes of www.2cto. comStruts 1 ActionForm are usually of the String type. Struts 1 uses Commons-Beanutils for type conversion. One converter for each class is not configurable. Struts 2 uses OGNL for type conversion and supports conversion between basic data types and common objects. 9. Data Verification: Struts1 supports manual verification by rewriting the validate method in ActionForm, or data verification by integrating the Commons-Validator framework. Struts2 supports verification by rewriting the validate method, and also supports integrating the XWork verification framework for verification 10. Action execution control: struts1 supports one request processing (the concept of lifecycle) for each module, but all actions in the module must share the same lifecycle. Struts2 supports creating an inaccessible life cycle for each Action through the interceptor stack. Developers can create corresponding heap searches as needed and use them with different actions. Bytes