Difference and comparison between struts1 and struts2 (Full Version)

Differences and comparison between struts1 and struts2:

Action class:
• Struts1 requires the action class to inherit an abstract base class. A common problem of struts1 is the use of abstract class programming rather than interfaces, while struts2's action is interfaces.
• The struts 2 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. The action interface is not required. Any pojo object with the execute identifier can be used as the action object of struts2.

Thread mode:
• Struts1 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 struts1 actions can do and requires caution during development. Action resources must be thread-safe or synchronized.
• The struts2 action object generates an instance for each request, so there is no thread security problem. (In fact, the servlet container generates many discarded objects for each request without causing performance and garbage collection problems)

Servlet dependency:
• The struts1 action depends on the servlet API, because when an action is called, httpservletrequest and httpservletresponse are passed to the execute method.
• Struts 2 action does not depend on the container, allowing the action to be tested independently from the container. If necessary, struts2 action can still access the initial request and response. However, other elements reduce or eliminate the need to directly access httpservetrequest and httpservletresponse.

Testability:
• A major problem in testing 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 simulated objects for testing ).
• Struts 2 action can be tested through initialization, setting attributes, and calling methods. "dependency injection" also makes testing easier.

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 to create traditional actionforms. However, developers may re-describe (create) the existing JavaBean (which still leads 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 modeldriven feature simplifies taglib's reference to pojo input objects.

Expression Language:
• Struts1 integrates jstl and therefore uses jstl el. This kind of El has basic object graph traversal, but the support for set and index attributes is weak.
• Struts2 can use jstl, but also supports a stronger and more flexible Expression Language-"object graph notation language" (ognl ).

Bind the value to the page (View ):
• Struts 1 uses the standard JSP mechanism to bind objects to pages for access.
• Struts 2 uses the "valuestack" technology to enable taglib to access values without binding your page (View) and objects. The valuestack policy allows you to reuse a page (View) through a series of attributes with the same name but different types ).

Type conversion:
• The struts 1 actionform attribute is generally of the string type. Struts1 uses commons-beanutils for type conversion. One converter for each class is not configurable for each instance.
• Struts2 uses ognl for type conversion. Provides Converters for basic and common objects.

Verification:
• Struts 1 supports manual verification in the validate method of actionform or through commons validator extension. The same class may have different verification content, but it cannot verify the child object.
• Struts2 supports verification through the validate method and xwork verification framework. The xwork verification framework uses the checksum defined for the attribute class type to support the chain checksum subattribute.

Control of Action execution:
• Struts1 supports a separate request processors (lifecycle) for each module, but all actions in the module must share the same lifecycle.
• Struts2 supports creating different lifecycles for each action through interceptor stacks. The stack can be used with different actions as needed.

I. Introduction The first version of struts was released in July. Its initial idea was to clearly separate the view and Business/application logic of Web applications by combining JSP and servlet. Before struts, the most common practice is to add business and application logic to JSP, or generate a view through println () in servlet.

Since its first release, Struts has become an industry-recognized web application standard. Its popularity has also brought about improvements and changes for itself. Therefore, we must not only keep up with the ever-changing demands on Web application frameworks, but also integrate with the features of a growing number of highly competitive frameworks. Finally, several next-generation struts solutions were created. Two of the most notable solutions are shale and Struts ti.

Shale is a component-based framework that has recently become a top-level project of Apache. Struts Ti continues to improve the front-end controller and Model-View-Controller Based on Struts's successful experience. The webwork project was released in March 2002. It revolutionizes the Struts framework and introduces many new ideas, concepts, and functions, but is not compatible with the original struts code. Webwork is a mature framework that has undergone several major improvements and releases. On July 6, December 2005, webwork and Struts Ti announced the merger. At the same time, Struts Ti was renamed struts Action Framework 2.0 and became the true successor of struts. Note that the development of the struts or webwork project has been stopped. Since people are still very interested in these two projects and many developers are still willing to use them, these two projects are still under development and bug fixing continues, improve features and add new features.

 

Ii. Differences between actions for those who have rich struts1.x development experience, they all know that action is the core content of the Struts framework. Of course, struts2 is no exception. However, the struts1.x and struts2 action models are very different. The most obvious difference between struts2 and struts1.x is that struts2 is a pull-MVC Architecture.

What does this mean? From the developer's point of view, it means that the data to be displayed to the user can be directly obtained from the action. Unlike struts1.x, the corresponding Bean must be saved to the page, request, or session to be obtained. Struts1.x must inherit from org. Apache. Struts. action. Action or its subclass. form data is encapsulated in formbean.

Struts 2 does not need to inherit any types or implement any interfaces. The form data is contained in the action and obtained through getter and setter (the following code example of actionforstruts2 ). Although, in theory, the struts2 action does not need to implement any interface or inherit any class, in actual programming, in order to implement the action more conveniently, in most cases, Com. opensymphony. xwork2.actionsupport class, And reload the string execute () method in this class (override.

First, we can see from actionforstruts2 that the returned object is not actionforward, but string. If you do not like to appear in your code as a string, a helper interface action can provide common results in constant mode, for example, "success", "NONE", "error", "input", and "login ".

In addition, in struts1.x, only the "execute" method can call action, but it is not necessary in struts2. Any declaration is Public String methodname () method, you can call action through configuration.

Finally, the biggest revolutionary difference between struts1.x and struts1.x is that struts2 does not include parameters in the methods called during action processing (the "execute" method.

How can we get the required objects? The answer is IOC (inversion control, inversion of control), also known as "dependency injection) (For more information, see Martin Fowler's article http://www.martinfowler.com/articles/injection.html ). The Spring framework makes this mode popular. However, the predecessor of struts2 (webwork) also applies this mode.

 

Iii. iocioc (inversion of control) is becoming increasingly familiar with the promotion of lightweight contianer in the Java Community. Here, you don't have to bother explaining "What is control reversal" and "why is it necessary to control reversal ". This is because many articles on the Internet have answered such questions brilliantly and accurately.

Readers can read "expert one-on-one J2EE development without EJB" by Rod Johnson and Juergen hoeller or "inversion of control containers and the dependency injection pattern" by Martin Fowler.. As we all know, struts2 is developed based on webwork 2. In webwork versions earlier than webwork 2.2, webwork 2.2 has its own set of control reversal implementations. In the context of the development of the Spring framework, webwork decided to abandon the development of the control reversal function, it is implemented by spring.

It is worth mentioning that spring is indeed a learning framework, because more and more open-source components (such as ibatis) abandon the development of overlapping features with spring. Therefore, struts2 recommends that you implement control inversion through spring.

To better understand the inversion control, let's take a look at an example. How can I use IOC to access the httpserverrequest object of the current request during action processing. In this example, the dependency injection mechanism is interface injection. Just like the name, interface injection requires an implemented interface.

This interface contains the setter of the corresponding attribute and provides a value for the action.

The servletrequestaware interface is used in the example, as follows:

Public interface servletrequestaware {public void setservletrequest (httpservletrequest request );}

After inheriting this interface, the original simple action looks a bit complicated, but you can get the httpserverrequest object to use it.

Public class iocforstruts2 implements servletrequestaware {

Private httpservletrequest request;

Public void setservletrequest (httpservletrequest request ){

This. Request = request ;}

Public String execute () throws exception {

// You can start to use the request object for work.

Return Action. success ;}

}

It seems that these attributes are class-level and are not thread-safe and may cause problems.

In fact, there is no problem in struts2, because each request will generate a new action object instance, which does not share an object with other requests, so thread security issues do not need to be considered.

Interceptor, which is used in AOP (Aspect-Oriented Programming) to intercept a method or field before or after it is accessed.

Interception is an implementation policy of AOP. In the Chinese Document of webwork, the interceptor is the object for dynamically intercepting action calls. It provides a mechanism for developers to define the code to be executed before and after an action is executed, or to prevent the code from being executed before an action is executed. It also provides a way to extract reusable parts of an action. The standard framework of struts1.x does not provide any form of interceptor. Although an additional project named Saif implements this function, its applicability is limited.

The Interceptor is a powerful tool of struts2. Many features are built on it, such as internationalization, converter, and validation. Interceptor chain, also known as interceptor stack in struts2, is a popular term for interceptor ).

The interceptor chain is to link the interceptor into a chain in a certain order. When accessing intercepted methods or fields, the interceptor in the interceptor chain will be called in the order defined previously.

The interceptor Implementation of struts 2 is relatively simple. When a request arrives at the servletdispatcher of struts2, Struts 2 searches for the configuration file, instantiates the relative interceptor object based on the configuration, and then Concatenates the object into a list ), finally, the interceptor in the list is called one by one. Struts 2 provides a wide range of functions to implement the interceptor.

The reader can go to the struts2-all-2.0.6.jar of the struts2-core-2.0.6.jar or struts-default.xml package to view the configurations about the default interceptor and interceptor chain. As a "Framework", scalability is indispensable, because there is nothing in the world.

Although struts 2 provides us with such rich interceptor implementations, it does not mean that we lose the ability to create custom interceptors. On the contrary, it is quite easy to define the interceptor in struts 2.

The previous section briefly introduced the origins of struts2 and compared the differences between struts2 and struts1.x in detail. Readers should have some knowledge about the basics of struts2-including high-level Framework concepts and basic request processes, understand the difference in action between struts1.x and struts2. struts2 enhances support for interceptor and IOC. In struts1.x, these features are hard to imagine.

At the same time, the reader should understand that struts2 is a webwork upgrade, not a struts 1.x upgrade. Although struts 2 is compatible with struts1.x, it is no longer an upgrade of struts1.x. For developers who already have struts1.x development experience, struts1.x development experience is not very helpful for struts2. On the contrary, for developers who already have webwork development experience, the development experience of webwork will be of great reference to the development of struts2.

Difference and comparison between struts1 and struts2 (Full Version)

Difference and comparison between struts1 and struts2 (Full Version)