<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>The Struts User's Guide - Building Model Components</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<meta content="Craig R. McClanahan" name="author" />
<meta content="Mike Schachter" name="author" />
<meta content="Ted Husted" name="author" />
<meta content="Martin Cooper" name="author" />
<meta content="Phil Steitz" name="author" />
<link href="../struts.css" type="text/css" rel="stylesheet" />
</head>
<body>
<div id="heading">
<a href="http://apache.org/">
<img id="asf_logo_wide" alt="The Apache Project" src="../images/asf_logo_wide.gif" />
</a>
<a href="http://struts.apache.org/">
<img id="struts-logo" alt="Struts Framework" src="../images/struts.gif" />
</a>
</div>
<!--end heading-->
<div id="content">
<div id="menu">
<p>User Guide</p>
<ul>
<li>
<a href="index.html">Table of Contents</a>
</li>
<li>
<a href="preface.html">Preface</a>
</li>
<li>
<a href="introduction.html">Introduction</a>
</li>
<li>
<a href="building_model.html">Model Components</a>
</li>
<li>
<a href="building_view.html">View Components</a>
</li>
<li>
<a href="building_controller.html">Controller Components</a>
</li>
<li>
<a href="configuration.html">Configuration</a>
</li>
<li>
<a href="release-notes.html">Release Notes</a>
</li>
<li>
<a href="installation.html">Installation</a>
</li>
</ul>
<p>Developer Guides</p>
<ul>
<li>
<a href="dev_bean.html">Bean Tags</a>
</li>
<li>
<a href="dev_html.html">HTML Tags</a>
</li>
<li>
<a href="dev_logic.html">Logic Tags</a>
</li>
<li>
<a href="dev_nested.html">Nested Tags</a>
</li>
<li>
<a href="dev_tiles.html">Tiles Tags</a>
</li>
<li>
<a href="dev_util.html">Utilities</a>
</li>
<li>
<a href="dev_validator.html">Validator</a>
</li>
</ul>
<p>Quick Links</p>
<ul>
<li>
<a href="../index.html">Welcome</a>
</li>
<li>
<a href="index.html">User and Developer Guides *</a>
</li>
<li>
<a href="../faqs/index.html">FAQs and HowTos</a>
</li>
</ul>
<div class="authors">
<p>
<strong>Contributors</strong>
</p>
<ul>
<li>Craig R. McClanahan</li>
<li>Mike Schachter</li>
<li>Ted Husted</li>
<li>Martin Cooper</li>
<li>Phil Steitz</li>
</ul>
</div>
</div>
<!--end menu-->
<div id="main">
<h1 id="building_model">2. Building Model Components</h1>
<h2 id="overview">2.1 Overview</h2>
<div class="indent">
<p>
Many requirements documents used for building web applications focus on
the <em>View</em>.
However, you should ensure that the processing required for each submitted
request is also clearly defined from the <em>Model's</em> perspective.
In general, the developer of the <em>Model</em> components will be focusing
on the creation of JavaBeans classes that support all of the functional
requirements.
The precise nature of the beans required by a particular application will
vary widely depending on those requirements, but they can generally be
classified into several categories discussed below.
However, a brief review of the concept of "scope" as it relates to beans
and JSP is useful first.
</p>
</div>
<h2 id="javabeans">2.2 JavaBeans and Scope</h2>
<div class="indent">
<p>
Within a web-based application, JavaBeans can be stored in (and accessed
from) a number of different collections of "attributes".
Each collection has different rules for the lifetime of that collection,
and the visibility of the beans stored there.
Together, the rules defining lifetime and visibility are called the
<em>scope</em> of those beans.
The JavaServer Pages (JSP) Specification defines scope choices using
the following terms (with the equivalent servlet API concept defined in
parentheses):
</p>
<ul>
<li>
<strong>page</strong> - Beans that are visible within a single JSP page,
for the lifetime of the current request.
(Local variables of the <code>service</code> method)
</li>
<li>
<strong>request</strong> - Beans that are visible within a single JSP page,
as well as to any page or servlet that is included in this page,
or forwarded to by this page.
(Request attributes)
</li>
<li>
<strong>session</strong> - Beans that are visible to all JSP pages and
servlets that participate in a particular user session, across one
or more requests.
(Session attributes)
</li>
<li>
<strong>application</strong> - Beans that are visible to all JSP pages and
servlets that are part of a web application.
(Servlet context attributes)
</li>
</ul>
<p>
It is important to remember that JSP pages and servlets in the same
web application share the same sets of bean collections.
For example, a bean stored as a request attribute in a servlet like this:
</p>
<p>
<code>MyCart mycart = new MyCart(...);<br />
request.setAttribute("cart", mycart);
</code>
</p>
<p>
is immediately visible to a JSP page which this servlet forwards to,
using a standard action tag like this:
</p>
<p>
<code><jsp:useBean id="cart" scope="request"<br />
class="com.mycompany.MyApp.MyCart"/>
</code>
</p>
</div>
<h2 id="actionform">2.3 ActionForm Beans</h2>
<div class="indent">
<strong>Note:</strong> While ActionForm beans often have properties that
correspond to properties in your Model beans, the form beans themselves
should be considered a Controller component.
As such, they are able to transfer data between the Model and View layers.
<p>
The Struts framework generally assumes that you have defined an
<code>ActionForm</code> bean (that is, a Java class extending the
<code>ActionForm</code> class) for the input forms in your
application.
<code>ActionForm</code> beans are sometimes just called "form beans".
These may be finely-grained objects, so that there is one
bean for each form, or coarsely-grained so that one bean serves
several forms, or even an entire application.
</p>
<p>
If you declare such beans in your Struts
configuration file (see "<a href="building_controller.html#config">
Building the Controller Components</a>"), the Struts controller servlet
will automatically perform the following services for you, before
invoking the appropriate <code>Action</code> method:
</p>
<ul>
<li>
Check for an instance of a bean of the appropriate class, under the appropriate key,
in the appropriate scope (request or session).
</li>
<li>
If there is no such bean instance available, a new one is
automatically created and added to the appropriate scope (request or session).
</li>
<li>
For every request parameter whose name corresponds to the name
of a property in the bean, the corresponding setter method will
be called. This operates in a manner similar to the standard
JSP action <code><jsp:setProperty></code> when you use the
asterisk wildcard to select all properties.
</li>
<li>
The updated <code>ActionForm</code> bean will be passed to the
<code>execute</code> method of an <code>Action</code> class
[<code>org.apache.struts.Action</code>], so that the values can
be made available to your system state and business logic beans.
</li>
</ul>
<p>
For more about coding <code>Actions</code> and <code>ActionForm</code>
beans, see the "<a href="building_controller.html">Building
Controller Components</a>" chapter.
</p>
<p>
You should note that a "form", in the sense discussed here, does not
necessarily correspond to a single JSP page in the user interface.
It is common in many applications to have a "form" (from the user's
perspective) that extends over multiple pages.
Think, for example, of the wizard style user interface that is commonly
used when installing new applications.
Struts encourages you to define a single <code>ActionForm</code> bean that
contains properties for all of the fields, no matter which page the field
is actually displayed on.
Likewise, the various pages of the same form should all be submitted to
the same Action Class.
If you follow these suggestions, the page designers can rearrange the
fields among the various pages, often without requiring changes to the
processing logic.
</p>
<p>
Smaller applications may only need a single ActionForm to service all of
its input forms.
Others applications might use a single ActionForm for each major subsystem
of the application.
Some teams might prefer to have a separate ActionForm class for each
distinct input form or workflow.
How many or how few ActionForms to use is entirely up to you.
The framework doesn't care.
</p>
</div>
<h2 id="system_state">2.4 System State Beans</h2>
<div class="indent">
<p>
The actual state of a system is normally represented as a set of one or
more JavaBeans classes, whose properties define the current state.
A shopping cart system, for example, will include a bean that represents
the cart being maintained for each individual shopper, and will (among
other things) include the set of items that the shopper has currently
selected for purchase.
Separately, the system will also include different beans for the user's
profile information (including their credit card and ship-to addresses),
as well as the catalog of available items and their current inventory
levels.
</p>
<p>
For small scale systems, or for state information that need not be kept
for a long period of time, a set of system state beans may contain all the
knowledge that the system ever has of these particular details.
Or, as is often the case, the system state beans will represent
information that is stored permanently in some external database (such as
a <code>CustomerBean</code> object that corresponds to a particular row in
the CUSTOMERS table), and are created or removed from the server's memory
as needed.
Entity Enterprise JavaBeans are also used for this purpose in large scale
applications.
</p>
</div>
<h2 id="business_logic">2.5 Business Logic Beans</h2>
<div class="indent">
<p>
You should encapsulate the functional logic of your application as
method calls on JavaBeans designed for this purpose.
These methods may be part of the same classes used for the system state
beans, or they may be in separate classes dedicated to performing the
logic.
In the latter case, you will usually need to pass the system state beans
to be manipulated to these methods as arguments.
</p>
<p>
For maximum code re-use, business logic beans should be designed and
implemented so that they do <strong>not</strong> know they are being executed in a
web application environment.
If you find yourself having to import a <code>javax.servlet.*</code> class
in your bean, you are tying this business logic to the web application
environment.
Consider rearranging things so that your <code>Action</code> classes (part
of the Controller role, as described below) translate all required
information from the HTTP request being processed into property setter
calls on your business logic beans, after which a call to an
<code>execute</code> method can be made.
Such a business logic class can be reused in environments other than the
web application for which they were initially constructed.
</p>
<p>
Depending on the complexity and scope of your application, business logic
beans might be ordinary JavaBeans that interact with system state beans
passed as arguments, or ordinary JavaBeans that access a database using
JDBC calls.
For larger applications, these beans will often be stateful or stateless
Enterprise JavaBeans (EJBs) instead.
</p>
<p>
For more about using a database with your application, see the
<a href="../faqs/database.html">Accessing a Database HowTo</a>.
</p>
</div>
<hr class="section" />
<div class="indent">
<p class="right">
Next: <a href="building_view.html">Building View Components</a>
</p>
</div>
</div>
<!--end main-->
</div>
<!--end content-->
<div id="footer">
<img id="powered-logo" alt="Powered by Struts" src="../images/struts-power.gif" />
Copyright (c) 2000-2005, The Apache Software Foundation <span class="noprint">-
<a href="http://wiki.apache.org/struts/StrutsDocComments">Comments?</a>
</span>
</div>
<!--end footer-->
</body>
</html>
