Differences between Struts1 and Struts2

1) Comparison of Action Implementation classes:
Struts 1 requires the Action class 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 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 synchronized;
The Struts 2 Action object generates 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 methods of Struts 1 Action include HttpServletRequest and HttpServletResponse.
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 parameters HttpServletRequest and HttpServletResponse, Struts
2 actions 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:
One 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 get rid of the Web container to test the Action of Struts 1, you must use the third-party Extension: Struts
TestCase. This extension contains a series of Mock objects (simulating the HttpServetRequest and HttpServletResponse objects), which can be used to 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 encapsulated 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. provide dynamic ActionForm to simplify the development of ActionForm, but still need to define ActionForm in the configuration file;
Struts 2 directly uses the Action attribute to encapsulate user request attributes, avoiding the hassle of developing a large number of ActionForm classes. In fact, these attributes can also be Rich object types containing sub-attributes. If developers still miss Struts
1. The ActionForm mode. Struts 2 provides the ModelDriven mode, which allows developers to use a separate Model object to encapsulate user request parameters. However, this Model object does not need to inherit any Struts 2 base classes, is a POJO, which reduces code pollution.
6) Comparison of expression language:
Struts 1 integrates JSTL, so you can use the JSTL Expression Language. 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, But it integrates a stronger and more flexible Expression Language: OGNL (Object Graph Notation Language). Therefore, the expression Language under Struts 2 is more powerful.
7)-Comparison of binding values to views:
Struts 1 binds an object to a view page using the standard JSP mechanism;
Struts 2 uses the "ValueStack" technology to enable the tag library to access the value without binding the object with the view page.
8) Comparison of type conversion:
The Struts 1 ActionForm attribute is generally of the String type. Struts 1 uses Commons-Beanutils for type conversion. Each class has one converter and the converter cannot be configured;
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 validate method of ActionForm rewriting, 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 one 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.
11) Capture input:
Struts1 uses the ActionForm object to capture input. All actionforms must inherit a base class. Because other JavaBean cannot be used as an ActionForm, developers often create redundant class capture inputs. Dynamic beans (DynaBeans) can be used as an option to create a traditional ActionForm. However, developers may re-describe (create) the existing JavaBean (which will still lead to redundant javabean ).
Struts 2 directly uses the Action attribute as the INPUT attribute, eliminating the need for the second input object. The INPUT attribute may be a rich object type with its own (sub) attribute. The Action attribute can be accessed through taglibs on the web page. Struts2 also supports the ActionForm mode. Rich object type, including business objects, which can be used as input/output objects. This
The ModelDriven feature simplifies taglib's reference to POJO input objects.

Blog Source: http://www.blogjava.net/314508313/archive/2011/11/17/364038.html