The structure of Java STRUTS2 Framework and its data transfer mode _java

The structure of the STRUTS2

1. Why use the framework?

(1) The framework automatically completes a lot of trivial tasks

For STRUTS2, it helps us to easily complete data type conversion, data validation, internationalization, and so on.
Common tasks in web development. And the large number of template patterns used in spring, are all for our development
The process is more automated and intelligent. Using the framework is to avoid reinventing the wheel and copying the template code again.
The framework lets us focus more on higher-level issues than on common workflows and basic tasks.

(2) Using the framework is to gracefully inherit the architecture behind the framework

The architecture behind the framework usually defines a series of workflows, and all we have to do is put the specific application code
Attached to this set of processes, you can enjoy the benefits of the framework. There are times when we can
Rebel against the framework rules, but the framework usually provides its architecture in a way that is difficult to deny. So simple
Can gracefully inherit an excellent architecture, and is free, why not?

(3) The use of frameworks is easier to find trained people

I used to be in the company of the entire project almost none of the frameworks, from service services to find (like Jndi)
To log printing (similar to log4j), and then to the database connection pool (similar to DBCP), all internal personnel
Realized. This is because the project is older, there may not be any open source framework for use, and secondly also because
The company's conservative strategy, fearing that using an unstable open source framework might pose a risk to the project. It was in the circumstances.
Perhaps it is true that the company's top brass will naturally consider the whole project from a larger perspective.

But as the project grows larger, and the world's best open source framework becomes more and more, if you can't reconstruct it in time
And the introduction of some mature open source framework, the final result may be that new developers must learn from the beginning
This complex system (both internal systems, no documentation help on the web), but also be careful of the internal framework of the various bugs,
The cost is really too high.

(4) The internal framework cannot keep up with the development of the industry

The bug in the internal framework is mentioned earlier. For the open source framework, there may be a framework founder team, a large number of open source enthusiasts,
Open source community to support. The people's power is infinite, the bug fixes the speed to be conceivable, this point from the recent open source's
The TextMate bug fix process can be seen. Many of the bugs that have been shelved for a long time have been quickly followed by enthusiasts
Solved, and the internal framework? After the people who developed him left the company, no one even had a major bug
To read his source code, the gap can be seen!

(5) Of course the use of the framework is not lucrative things

As mentioned earlier, it is risky to use an immature framework for a project that is not so radical or conservative.
(unless it's a group of free and unfettered technology fanatics who can decide what framework to use, that's a happy thing)
Like the Java Ha high-availability service Sequioa I've used before, this framework is ultimately no longer supported by development companies
, then the risk is even greater.

In addition, the use of some unusual framework also pay attention to the framework Source Code license Protocol, not in the project arbitrary reference,
Modify the framework of the source code so as not to cause unnecessary legal disputes.

the architecture behind 2.struts2

Now that we have analyzed the benefits of the framework, we will naturally begin to learn how to use STRUTS2. But using Struts2
What kind of elegant architecture would you inherit? In fact, from a higher level of abstraction, it is still familiar with the MVC pattern.

Corresponding to the previous HelloWorld example, Controller C (filterdispatcher) is what we declared in Web.xml
Struts2 Core class. and Model M is our Newsaction action class. and view V is naturally news.jsp. Model
The concept seems somewhat vague, what is the model? In fact, this sounds very noun concept in Struts2 contains both static
The business data from the front end of the web also contains the implementation of the business logic.

One might say that there is nothing new about this architecture, there are many MVC frameworks, what's the difference between the frameworks? Let us
Stand at the lower level of abstraction and dissect the Struts2 to see what's different.

At first glance very complex, if only from the user point of view, in development we only need to implement the yellow part, that is, we
HelloWorld the Struts.xml,newsaction and news.jsp in the instance. That's all we have to do, just like the front
said, only need to do very few things, we become a part of this excellent architecture.

Now look at the other parts. Filterdispatcher is the servlet filter we've configured in Web.xml, which is Struts2
Portal, all STRUTS2 Web applications are configured this way. The next blue and green part is the core of Struts2.
, it can be said that these classes are designed by the STRUTS2 developers in a well-designed architecture.

(1) The client sends the request, the Java-ee container resolves the HTTP package and encapsulates it into a httpservletrequest.

(2) Filterdispatcher intercepts the request and determines which action to invoke based on the request path to the Actionmapper query.

(3) According to Actionmapper's return results, Filterdispatcher commissioned Actionproxy to Struts.xml to find this action.

(4) Actionproxy creates a actioninvocation and begins a recursive call to the interceptor and the action.

(5) Each interceptor to complete their respective tasks

(6) A real call to the action, returning the result path

(7) The result object outputs the returned data to the stream

(8) Return httpservletresponse to the Java EE container, the container sends HTTP packets to the client.

This is the STRUTS2 implementation process, the core objects are actioninvocation and interceptor, as well as actioncontext not yet introduced.
Actioninvocation is the total schedule for the entire process, which is similar to the invocation object in spring AOP. And Interceptor has a lot
Are Struts2, the most important thing is to save the request parameters and pass the foreground data to the member variable of the action.

The Actioncontext is the global context object that holds the data, and most importantly, the valuestack that holds the action instance.
The term "global" means that Actioncontext can be accessed in action and result, but it is threadlocal type. Each request thread
will have their own action and Actioncontext instances.

It can be said that learning Struts2 is mainly learning:

(1) Let interceptor and action work together to complete the task.

(2) Save the foreground data to the action.

(3) Result returns data from action through Valuestack.

different points between 3.struts2 and Struts1

The great difference between Struts1 and 2 can already be seen from the execution process above.

(1) Where's actionform? Action or that action?

The obvious thing is that we don't see the Actionform object in the whole process, and the action is called that name, but
Seems to have been completely different from the action in Struts1.

First Actionform was abandoned, the data from the foreground can be saved to any pojo. First save to Actionform and then copy
The day of the Dto object has passed. Second, this pojo is actually a member variable in the Action object. It's in Struts1.
It is not possible for all requests to share an action instance, and now Struts2 will create an action instance for each request, so
It makes sense to do so. Third, while this works, it looks as though the action as the model M in MVC preserves both data and
Contains the business logic, is this not a bad design ah? Actually think about it, this design is very convenient, we have got the data,
The service layer can be operated directly. The role of action seems to be much, but not much.

(2) How did the front-end servlet become filter?

We know that Struts1 and spring MVC are portals through the front-end servlet, why Struts2 use a servlet filter?
Because Struts2 is based on the WebWork core, and Struts1 has been completely different. WebWork can be said to have lowered the app with Java EE
The coupling of APIs, such as converting Actionservlet to servlet filter, and then direct access to Httpservletrequest/response,
And if any pojo can assume the role of actionform, any class can be used as an action without implementing the action interface, etc.
So Struts2 also inherited this excellent non-invasive design.

This is somewhat like the spring design idea. such as those Ware interface, do not care about the beans do not need to implement, as far as possible to reduce the application
Coupling of program code and framework. Intrusion is indeed an important factor to consider when designing a framework.

(3) The adhesive ognl between Filter, Action and result

The diagram below shows a clear picture of how OGNL fit into the STRUTS2 framework.

It is so convenient to enter the page inputform.html and return pages resultpage.jsp use the STRUTS2 tag to access the data in the action
OGNL makes accessing the properties of the action saved in Valuestack as convenient as accessing Valuestack's own properties.

The extensive use of OGNL is a major feature of Struts2. Including the foreground tag pass value to Action,result from the action of the value and so will be a lot of
Used to OGNL. And OGNL is a lot of use of reflection, I think perhaps this is Struts2 performance than Struts1 a reason bar. After all, gained
Flexible and low coupling architectures are at the same time paying a certain price.

(4) The strong of interceptor is invincible strong

Another powerful feature of the STRUTS2 is the Interceptor interceptor. A large number of interceptors are built into the Struts2, and interceptors enable a large number of code to
Reuse, automate what we call trivial tasks before, so that Struts2 reaches a high level of concern for separation. This is really an AOP idea.
The paradigm of application in the framework!

Struts2 Three ways of data transfer
Struts2 provides JavaBean properties, JavaBean objects, and Modeldriven objects in three ways to hold the parameters in the HTTP request. Below through one of the most common
Login examples to see the three ways of data transfer. The page code is very simple, the submission form contains a username and password, which are given in the action to
Verify that the user is logged on successfully.

First, JavaBean properties

 <%@ page contenttype= "Text/html;charset=utf-8"%>  
 

Package com.cdai.web.ssh.action; 
 
Import Com.cdai.web.ssh.request.LoginRequest; 
Import Com.cdai.web.ssh.service.UserService; 
Import com.opensymphony.xwork2.Action; 
Import Com.opensymphony.xwork2.ModelDriven; 
 
public class Loginaction implements Action { 
 
  private String username; 
   
  private String password; 
   
  Private UserService UserService; 
   
  @Override public 
  String execute () { 
     
    System.out.println ("Login action-" + request); 
     
    return SUCCESS; 
  } 
 
  Public String GetUserName () {return 
    request; 
  } 
 
  public void Setusername (String username) { 
    this.username = username; 
  } 
   
  Public String GetPassword () {return 
    request; 
  } 
 
  public void SetPassword (String Password) {this 
    . Password = Password; 
  } 
   
 

This is a simpler way to save the parameters in the form directly to the properties in the action. The action may also need to encapsulate the user name and password as a dto when validating
The form is passed to the service layer for verification. So why not go further and save the username and password directly to the DTO.

second, the JavaBean object

<%@ page contenttype= "Text/html;charset=utf-8"%> 
 
 
 

Package com.cdai.web.ssh.action; 
 
Import Com.cdai.web.ssh.request.LoginRequest; 
Import Com.cdai.web.ssh.service.UserService; 
Import com.opensymphony.xwork2.Action; 
Import Com.opensymphony.xwork2.ModelDriven; 
 
public class Loginaction implements Action { 
 
  private loginrequest request; 
   
  Private UserService UserService; 
   
  @Override public 
  String execute () { 
     
    System.out.println ("Login action-" + request); 
     
    return SUCCESS; 
  } 
 
  Public Loginrequest Getrequest () {return 
    request; 
  } 
 
  public void Setrequest (Loginrequest request) { 
    this.request = Request; 
  } 
   
} 

This makes it easy to call the service layer directly. But one small drawback is that this deepens the depth of the page parameter name, and only adds the request to the parameter name
Prefix (the property name in action) to enable STRUTS2 to correctly save the parameters in the form to the request object through OGNL.

Third, Modeldriven objects

 <%@ page contenttype= "Text/html;charset=utf-8"%>  
 

Package com.cdai.web.ssh.action; 
 
Import Com.cdai.web.ssh.request.LoginRequest; 
Import Com.cdai.web.ssh.service.UserService; 
Import com.opensymphony.xwork2.Action; 
Import Com.opensymphony.xwork2.ModelDriven; 
 
public class Loginaction implements Action, modeldriven<loginrequest>  
{ 
 
  private loginrequest request = New Loginrequest (); 
   
  Private UserService UserService; 
   
  @Override public 
  String execute () { 
     
    System.out.println ("Login action-" + request); 
     
    return SUCCESS; 
  } 
 
  @Override public 
  loginrequest Getmodel () {return 
    request 
  } 
   
} 

This way to implement a more Modeldriven interface, the Modeldriven provided by the object also saved to the Valuestack, so that the front page can be directly through the
Username and password property names to define the parameter names of the form.

Three ways to specifically use which can not be generalized, or see the specific needs of the project and then set yourself!