Shulou(Shulou.com)06/02 Report--

This article mainly introduces what is the difference between Struts1 and Struts2, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

Classes for Struts1 and Struts2:

◆ Struts1 requires the Action class to inherit an abstract base class. A common problem with Struts1 is programming with abstract classes rather than interfaces.

The ◆ Struts 2 Action class can implement an Action interface as well as other interfaces, making optional and customized services possible. Struts2 provides an ActionSupport base class to implement common interfaces. The Action interface is not required, and any POJO object identified by execute can be used as an Action object for Struts2.

Thread mode:

◆ Struts1 Action is singleton and must be thread-safe because there is only one instance of Action to handle all requests. The singleton policy limits what Struts1 Action can do, and you have to be very careful when developing. 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 produces many disposable objects for each request and does not cause performance and garbage collection problems.)

Servlet dependencies for Struts1 and Struts2:

◆ Struts1 Action depends on 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 Action to be tested separately from the container. Struts2 Action can still access the original request and response if needed. However, other elements reduce or eliminate the need for direct access to HttpServetRequest and HttpServletResponse.

Testability of Struts1 and Struts2:

One of the main problems with ◆ testing Struts1 Action is that the execute method exposes servlet API (which makes the test 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, and dependency injection support makes testing easier.

Capture input for Struts1 and Struts2:

◆ Struts1 uses the ActionForm object to capture input. All ActionForm must inherit a base class. Because other JavaBean cannot be used as ActionForm, developers often create redundant classes to capture input. Dynamic Bean (DynaBeans) can be used as an option for creating a traditional ActionForm, but developers may be redescribing (creating) an existing JavaBean (which can 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 property may be a rich object type with its own (child) properties. The Action property 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 languages for Struts1 and Struts2:

◆ Struts1 integrates with JSTL, so it uses JSTL EL. This EL has basic object graph traversal, but weak support for collection and index properties.

◆ Struts2 can use JSTL, but it also supports a more powerful and flexible expression language, Object Graph Notation Language (OGNL).

Bound values of Struts1 and Struts2 to the page (view):

◆ Struts 1 uses the standard JSP mechanism to bind objects to the page for access.

◆ Struts 2 uses "ValueStack" technology to enable taglib to access values without having to bind your view to objects. The ValueStack policy allows pages to be reused (view) through a series of attributes with the same name but different types.

Type conversion for Struts1 and Struts2:

The ◆ Struts 1 ActionForm attribute is usually of type String. Struts1 uses Commons-Beanutils for type conversion. One converter per class is not configurable for each instance.

◆ Struts2 uses OGNL for type conversion. Provides converters for basic and commonly used objects.

Check of Struts1 and Struts2:

◆ Struts 1 supports manual verification in the validate method of ActionForm, or verification through an extension of Commons Validator. The same class can have different validation contents, but not child objects.

◆ Struts2 supports validation through the validate method and the XWork verification framework. The XWork validation framework uses the checksum content checksum defined for the attribute class type to support chain checksum child attributes

Controls performed by Struts1 and Struts2 Action:

◆ Struts1 supports a separate Request Processors (life cycle) for each module, but all Action in the module must share the same life cycle.

◆ Struts2 supports the creation of a different life cycle for each Action through the interceptor stack (Interceptor Stacks). The stack can be used with different Action as needed.

Thank you for reading this article carefully. I hope the article "what's the difference between Struts1 and Struts2" shared by the editor will be helpful to you. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.