The high-level design of Struts 2 follows the well-established Model-View-Controller design pattern.
The MVC design pattern identifies three distinct concerns: model, view, and controller.
In Struts 2, these are implemented by the action, result, and FilterDispatcher, respectively.
An application has any number of actions to handle whatever set of commands it exposes to the client. The controller, after receiving the request, must consult its mappings and determine which of these actions should handle the request.
Once it finds the appropriate action, the controller hands over control of the request processing to the action by invoking it. This invocation process, conducted by the framework, will both prepare the necessary data and execute the action’s business logic. When the action completes its work, it’ll be time to render a view back to the user who submitted the request. Toward this end, an action, upon completing its work, will forward the result to the Struts 2 view component.
CONTROLLER—FILTERDISPATCHER :
The controller’s job is to map requests to actions.
The role of the controller is played by the Struts 2 FilterDispatcher.
This important object is a servlet filter that inspects each incoming request to determine which
Struts 2 action should handle the request. You just need to inform the framework which request URLs map to
which of your actions. You can do this with XML-based configuration files or Java annotations.
MODEL—ACTION :
The model is implemented by the Struts 2 action component.
The model is the internal state of the application.
This state is composed of both the data model and the business logic.
A Struts 2 action serves two roles.
* First, an action is an encapsulation of the calls to business logic into a single unit of work.
* Second, the action serves as a locus of data transfer.
VIEW—RESULT :
The view is the presentation component of the MVC pattern.
In the figure, the FilterDispatcher has already done its controller work by selecting the appropriate action to handle the request. The figure demonstrates what really happens when the action is invoked by the controller.
INTERCEPTORS
There is a stack of interceptors in front of the action.
The invocation of the action must travel through this stack.
most every action will have a stack of interceptors associated with it.
These interceptors are invoked both before and after the action
Interceptors don’t necessarily have to do something both times they fire, but they do have the opportunity.
Some interceptors only do work before the action has been executed, and others only do work afterward.
The important thing is that the interceptor allows common, cross-cutting tasks to be defined in clean, reusable components that you can keep separate from your action code.
What kinds of work should be done in interceptors? Logging is a good example.
Logging should be done with the invocation of every action, but it probably shouldn’t be put in the action itself.
Why? Because it’s not part of the action’s own unit of work. It’s more administrative, overhead if you will.
Earlier, we charged a framework with the responsibility of providing built-in functional solutions to common domain tasks such as data validation, type conversion, and file uploads. Struts 2 uses interceptors to do this type of work.
While these tasks are important, they’re not specifically related to the action logic of the request. Struts 2 uses
interceptors to both separate and reuse these cross-cutting concerns. Interceptors play a huge role in the Struts 2 framework.
THE VALUESTACK AND OGNL
The ValueStack is a storage area that holds all of the data associated with the processing of a request.
OGNL (Object-Graph Navigation Language) is the tool that allows us to access the data we put in that central repository.
More specifically, it is an expression language that allows you to reference and manipulate the data on the ValueStack.