Difference between struts and struts2

1. Comparison of Action Implementation classes: struts 1 requires action classes to inherit an abstract base class; a specific problem of struts 1 is that it uses Abstract class programming instead of interfaces. Struts 2 Action class can implement an action interface or other interfaces to make optional and customized services possible. Struts 2 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 struts 2.

2. Comparison of thread modes: struts 1 action is a singleton mode and must be thread-safe, because only one instance of action is used to process all requests. The Singleton policy limits what struts 1 action can do and requires caution during development. Action resources must be thread-safe or synchronous. Struts 2 action objects generate an instance for each request, so there is no thread security problem.

3 servlet dependency comparison: struts 1 action depends on servlet API, because the execute method of struts 1 action contains the httpservletrequest and httpservletresponse methods. Struts 2 Action no longer depends on the servlet API, 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, Struts 2 action can still access them. However, most of the time, actions do not need to directly access httpservetrequest and httpservletresponse, thus giving developers more flexible choices.

4. Comparison of testability: a major problem in testing struts 1 action is that the execute method depends on the servlet API, which makes the test of action dependent on the Web container. To test the action of struts 1 from a Web Container, you must use a third-party Extension: struts testcase, which contains a series of mock objects (simulating the httpservetrequest and httpservletresponse objects ), in this way, you can test the action class of struts 1 from the Web container. Struts 2 action can be tested by initializing, setting properties, and calling methods.

5. Comparison of encapsulation request parameters: struts 1 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 struts 1 provides dynamic actionform to simplify the development of actionform, it still needs to define actionform in the configuration file; struts 2 uses the Action property 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 struts 1 actionform mode, Struts 2 provides the modeldriven mode, which allows developers to use separate model objects to encapsulate user request parameters, however, this model object does not need to inherit any struts 2 base class and is a pojo, which reduces code pollution.

6 Expression Language Comparison: struts 1 integrates jstl, so jstl can be used. This expression language provides basic object graph traversal, but does not have a strong function in support of set and index attributes. Struts 2 can use jstl, however, it integrates a more powerful and flexible Expression Language: ognl (object graph notation language). Therefore, the expression language function in struts 2 is more powerful.

7. Comparison of binding values to views: struts 1 binds objects to view pages using the standard JSP mechanism; struts 2 uses the valuestack technology to enable the tag library to access values, you do not need to bind the object with the view page.

Comparison of type conversion: the struts 1 actionform attribute is 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 comparison of data verification: struts 1 supports manual verification in the actionform override validate method, or data verification by integrating the commons alidator framework. Struts 2 supports validation by rewriting the validate method, and also supports validation by integrating the xwork verification framework.

10 comparison of action execution control: struts 1 supports a request processing (the concept of lifecycle) for each module, but all actions in the module must share the same lifecycle. Struts 2 supports creating different lifecycles for each action through the interceptor stacks. Developers can create corresponding stacks as needed and use them with different actions.