The high level design of Struts 2 follows the well established Model-View-Controller design pattern.
The MVC pattern provides a separation of concerns that applies well to the domain of web applications. Separation of concerns allows us to manage the complexity of large software systems by dividing them into high level components. The MVC design pattern identifies three distinct concerns: model, view and controller. In Struts 2 these concerns are implemented by the action, result and FilterDispatcher, respectively.
Controller – FilterDispatcher
It just seems to make more sense to start with the controller when talking about web applications. In
fact, the MVC variant used in Struts is often referred to as a front controller MVC. This basically
means that the controller is out front and is the first component to act in the processing. The controller’s job is to map requests to actions. In a web application, the incoming HTTP requests can each be thought of as commands that the user issues to the application. One of the more fundamental tasks of a web application is the routing of these requests to the appropriate set actions that should be taken with in the application itself. This controller’s job is like that of a traffic cop, or air traffic controller. In some ways, this work is
pretty administrative. Its certainly not part of your core business logic.
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. The framework pretty much handles all of the controller work for you. You just
need to inform the framework which request URL’s map to which of your actions. You can do
this with XML based configuration files, or with Java annotations.
Pull-out: Struts 2 goes along way towards a goal of zero-configuration web applications.
Zero-configuration aims at deriving all of an applications meta-data, such as which URL
maps to which action, from convention rather than configuration. The use of Java
annotations play an important role in this zero-configuration scheme. While zeroconfiguration
has not quite achieved its goal, you can currently use annotations and
convention to drastically reduce XML based configuration.
Model – Action
What exactly is the model? I personally find the model the most nebulous of the MVC triad. In some ways, the model is a black box that contains the entire guts of the application. Everything else is just user interface, and wiring. The model is the thing itself. In more technical terms, the model is the internal state of the application. This state is composed of both the data model and the business logic. From the high level black box view, the data and the business logic kind of merge together into the monolithic state of the application. For instance, if you are logging in to an application, we know that both business logic and data from the database will be involved in the authentication process. Most likely, a the business logic will provide an authentication method that will take the username and password and verify them against some
persisted data from the database. In this case, the data and the business logic combine together to
form one of two states, “authenticated” or “unauthenticated.” The data on its own, nor the
business logic on its own, can produce these states.
Bearing all of this in mind, 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. Its a bit early to go into details on this, but we will certainly treat this
in great depth during the course of this book. At this point, consider that 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 will forward to the Struts 2 view
component, the result – which we will now consider.
View – Result
The view is the presentation component of the MVC pattern. This page is the user interface which
presents a representation of the application’s state to the user. These are commonly JSP pages,
Velocity templates or some other presentation layer technology. While there are many choices
for the view, the role of the view is pretty clear cut and simple; it translates the state of the
application into a visual presentation with which the user can interact. With rich clients and Ajax
applications increasingly complicating the details of the view, it becomes even more important to
have clean MVC separation of concerns. Good MVC lays the ground work for easy management
of the most complex front end.
Pull-out: One of the interesting aspects of Struts 2 is how well its clean architecture paves
the way for new technologies and techniques. The Struts 2 result component is a good
demonstration of this. The result provides a clean encapsulation of the processing of
handing off control of the processing to another object that will write the response to the
client. This makes it very easy for alternative responses, such as XML Ajax snippets or
XSLT transformations, to be integrated into the framework.
The action is responsible for choosing which result will render the response. The action can choose from any number of results with which it might have been associated. Common choices are between results that represent the semantic outcomes of the action’s processing, such as ‘success’ and ‘error’. Struts 2 provides out of the box support for using most common view layer technologies as results. These include JSP,
Velocity, FreeMarker, and XSLT . Better yet, the clean structure of the architecture insures that
more result types can be easily built to handle new types of responses.
Now that we’ve met the MVC components of the framework, you should probably have a
general idea of how Struts 2 handles the workflow of a web application.
