Comparison of Springmvc and Struts2

These things are basically I paste from the Internet, not so much patience and time a word a word of the knock, but the basic can show that I choose Springmvc ideas and reasons.

Put this picture here, I want to say Springmvc and Struts2 really is not the same, although in all have the core distributor , such as the same functional components (these are determined by the MVC pattern itself).

Why would SPRINGMVC win the final victory? Talk about some of my own views:

First, the MVC framework appears to map URLs from the world of HTTP to the Java world, which is the core function of the MVC framework. And at the URL this point Springmvc undoubtedly more elegant.

Second, from the perspective of design, I think springmvc more clear. Even if we were to compare Struts2 's schematic with Springmvc's class diagram, it was still confusing, far from Springmvc more intuitive:

SPRINGMVC design ideas: Standardize the entire process and assign each process step to a different component for processing.

This scenario actually involves two areas:

L Processing Process Normalization-divides the processing process into several steps (tasks) and concatenates all the steps using a clear logical main line

L Process component-defines each step (task) in the processing process as an interface and assigns different implementation patterns to each interface

The process normalization is the purpose, and the procedure and process definition of the process are the means. Thus, the primary content of process normalization is to consider the logical steps that a generic servlet responder should roughly include:

L step to the HTTP request for preliminary processing, find the corresponding Controller processing class (method)--handlermapping

L Step 2--Call the appropriate Controller processing class (method) to complete the business logic--handleradapter

L Step 3--Handle exceptions that can occur when a controller processes a class (method) Call--handlerexceptionresolver

L Step 4--HTTP Response processing based on the call result of the Controller processing class (method)--viewresolver

It is this design based on component and interface that supports another feature of SPRINGMVC: the extensibility of behavior.

Thirdly, the design principle is more clear.

"Open for extension/closed for modification"

This important design principle is written in the beginning of the SPRINGMVC chapter of Spring's official reference: A key design principle in Springweb MVC and in spring Open for extension, closed for modification "principle.

And the emphasis is well embodied in the implementation of the SPRINGMVC, can be expanded, but cannot be changed. I have extended the spring IOC, AOP features, which should be SPRINGMVC with spring same strain.

Finally, the modular design and the specific design principles let the springmvc-shaped scattered god gather.

• God--springmvc always runs along a fixed logical line.
• --SPRINGMVC has many different behavioral patterns.

SPRINGMVC is a component-based development framework in which different implementations of components form a "form", and the logical concatenation of components constitutes "God". Therefore, the "scattered God does not disperse": SPRINGMVC's logical Main line is always the same, but the behavior pattern can be varied.

Five, more closely conform to the trend of web development, this is more virtual, no longer talk about this problem.

The technical slowdown resulted in the programmer losing enthusiasm for Struts2, which led Springmvc to rely on his own efforts and spring's reputation, gradually revealing its own advantages and characteristics.

Why would SPRINGMVC win the final victory? Finally, we might as well think about how Struts2 is popular!

I used to come from the Struts1, and later Struts1 the problem is obvious, the open source community appeared a lot of MVC framework, the most prominent is WEBWORK2.

WEBWORK2 explored a different solution from the traditional servlet model, and was gradually known and understood, and developed and recognized by the majority of programmers. With excellent design ideas and flexible implementation, it attracts a large number of web-layer developers into its embrace.

The Apache community and Opensymphony announced that the future Struts project will be merged with the WEBWORK2 Project and launched jointly with STRUTS2.

STRUTS2 's ability to dominate the development market over a long period of time is due to its technological leadership. The leading edge of this technology is highlighted by a thorough transformation of the controller:

public class Usercontroller {

Private User User

Public String execute () {

Add business logic code here

Return "Success";

}

}

From the code above, we can see that Webwork2/struts2 has two points for the controller's biggest retrofit:

• The introduction of native servlet objects such as HttpServletRequest or HttpServletResponse is completely eliminated in the controller.
• Both the request parameter and the response data are stripped from the response method to the property variables in the controller.

These two major transformation is regarded as the genius of the frame. Because of this transformation, the entire controller class is completely decoupled from the Web container and can be easily carried out in unit testing. And get rid of the servlet bound controller, but also for the entire programming model to give a new definition. From the perspective of introducing new programming elements, WEBWORK2/STRUTS2 is undoubtedly a success. Because the attribute variables in the off-limits controller in the traditional servlet pattern are reasonably utilized as part of the data in the request processing process. This transformation not only allows the expression engine to be maximized, but also makes the entire controller look more like a pojo. Thus, this form of expression is named by the Author: Pojo implementation mode. The Pojo implementation pattern is a revolutionary pattern because it is able to maximize the idea of decoupling. From an object-oriented perspective, the Pojo pattern is undoubtedly one of the goals that all programmers pursue. This is one of the important reasons why Webwork2/struts2 has been enduring for so many years.

So, the first reason we see this is that STRUTS2 relies on technological innovation to win the favor of programmers. But the Struts2 of technological innovation over the years seems to have taken a smaller stride. We can see that after the popularization of JDK1.5, annotation as a new Java syntax, is gradually known and applied. This point Springmvc followed the trend of the times, directly for the request-response mapping. But Struts2 has been unable to form a breakthrough in the single configuration source. Of course, this is just a simple example of technological innovation, and there are many other examples.

At least that's the way it feels to people. Struts is not very dipping at this point, as spring's word of mouth and influence also objectively deepens everyone's impression of SPIRNGMVC as a technology leader.

Comparison of Springmvc and Struts2