The difference and contrast between Struts1 and Struts2

Source: Internet
Author: User

Differences and contrasts between Struts1 and Struts2:

Action class:
STRUTS1 requires the action class to inherit an abstract base class. A common problem with Struts1 is the use of abstract class programming instead of interfaces.
The Struts 2 action class can implement an action interface or other interfaces to make possible optional and custom services. STRUTS2 provides a actionsupport base class to implement commonly used interfaces. The action interface is not required, and any Pojo object that has an execute identity can be used as the Struts2 action object.

Threading Mode:
The struts1 action is a singleton pattern and must be thread-safe because only one instance of the action handles all requests. The singleton strategy limits what Struts1 action can do, and is especially careful when developing. The action resource must be thread-safe or synchronous.
The struts2 Action object generates an instance for each request, so there is no thread safety issue. (In fact, the servlet container produces many objects that can be discarded for each request and does not cause performance and garbage collection issues)

Servlet dependencies:
The struts1 action relies on the servlet API because HttpServletRequest and HttpServletResponse are passed to the Execute method when an action is invoked.
Struts 2 Action does not depend on the container, allowing the action to be tested separately from the container. If required, the STRUTS2 action can still access the initial request and response. However, other elements reduce or eliminate the need for direct access to Httpservetrequest and HttpServletResponse.

Testability:
• One of the main problems in testing the STRUTS1 action is that the Execute method exposes the servlet API (which makes the test dependent on the container). A third-party extension--struts testcase--provides a set of Struts1 mock-up objects (to be tested).
Struts 2 action can be tested by initializing, setting properties, calling methods, and "Dependency injection" support makes testing easier.

Capture Input:
Struts1 uses the Actionform object to capture the input. All Actionform must inherit a base class. Because other JavaBean cannot be used as actionform, developers often create extra class-capture inputs. Dynamic Beans (Dynabeans) can be used as a choice for creating traditional actionform, but developers may be re-describing (creating) existing JavaBean (still causing redundant javabean).
Struts 2 uses the Action property directly as an input property, eliminating the need for a second input object. The input attribute may be a rich object type with its own (child) attribute. The Action property can be accessed through taglibs on a Web page. STRUTS2 also supports Actionform mode. Rich object types, including business objects, that can be used as input/output objects. This modeldriven feature simplifies taglib references to pojo input objects.

Expression language:
Struts1 integrates the Jstl, so the Jstl EL is used. This El has a basic object graph traversal, but support for collections and indexed properties is weak.
Struts2 can use Jstl, but it also supports a more powerful and flexible expression language-"Object Graph Notation Language" (OGNL).

Bind value to page (view):
Struts 1 uses the standard JSP mechanism to bind objects to pages for access.
Struts 2 uses "valuestack" technology to enable taglib to access the values without having to bind your page (view) and objects together. The Valuestack policy allows pages (view) to be reused through a series of properties with the same name but different types.

Type conversions:
The Struts 1 Actionform property is usually of type string. Struts1 uses commons-beanutils for type conversion. Each class is a converter that is not configurable for each instance.
Struts2 uses OGNL for type conversion. A converter that provides basic and common objects.

Check:
The Struts 1 supports manual validation in the Validate method of the Actionform, or is verified by an extension of Commons validator. The same class can have different checksum content, but it cannot validate child objects.
STRUTS2 supports validation through the Validate method and the Xwork check framework. The Xwork checksum framework uses checksum content validation defined for the attribute class type to support the chain check sub-property

Control of Action Execution:
Struts1 supports each module with a separate request processors (life cycle), but all the actions in the module must share the same life cycle.
Struts2 supports creating different lifecycles for each action through the Interceptor Stack (Interceptor Stacks). Stacks can be used in conjunction with different actions as needed.

The difference and contrast between Struts1 and Struts2

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.