Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

1.5 Why Is Model-View-Controller So Important?

The MVC architectural pattern is not
directly related to web applications or Java for that matter. In
fact, it's quite common in Smalltalk applications,
which generally have nothing to do with the Web.

As we saw in the previous section, the Model 2 approach is concerned
with separating responsibilities in web applications. Allowing a JSP
page to handle the responsibilities of receiving the request,
executing some business logic, and then determining the next view to
display can make for an unattractive JSP page, not to mention the
maintenance and extensibility problems this entanglement causes.
Application development and maintenance are much easier if the
different components of a web application have clear and distinct
responsibilities.

The MVC pattern is categorized as a design pattern in many software
design books. Although there is much disagreement on the precise
definition of the pattern, there are some fundamental ideas.

The MVC pattern has three key
components:

Model

Responsible for the business
domain state knowledge

View

Responsible for a presentation
view of the business domain

Controller

Responsible for controlling
the flow and state of the user input

With the MVC pattern, a form of event notification usually takes
place to notify the view when some portion of the model changes.
However, because a browser in a typical web application has a
stateless
connection, the notification from the model to the view cannot occur
easily.^[2] Of course, an
application could perform some type of push mechanism to push
notification or data all the way to a client, but this is overkill
for most web applications. A user can close the browser at any time,
and generally no notification is sent to the server. A great deal of
overhead is necessary to manage remote clients from the server side.
This type of behavior is not necessary for typical web applications.

^[2] Web applications are considered stateless
because the browser doesn't maintain a constant open
connection to the web server. However, a web application still may
maintain session data for a user or even store data within the
browser on behalf of the user.

With standard web applications, a client typically sends another
request to the server to learn about any changes to the model. This
is known as a "pull" approach. For
example, if a user is viewing pricing information for an item and at
the same time the administrator changes the price for that item, the
user will not know it changed until he refreshes the page.

1.5.1 The MVC Model

Depending on the type
of architecture your application uses, the model portion of the MVC
pattern can take many different forms. In a two-tier application,
where the web tier interacts directly with a data store such as a
database, the model classes may be a set of regular Java objects.
These objects may be populated manually from a
ResultSet returned by
a database query, or they may be instantiated and populated
automatically by an object-to-relational
mapping (ORM) framework such as
TopLink or
CocoBase.

In a more complex enterprise application (where the web tier
communicates with an EJB server, for example), the model portion of
the MVC pattern will be Enterprise JavaBeans. Although the EJB
2.0 specification made performance improvements through the use of
local interfaces, there still can be a significant performance impact
if the web tier attempts to use entity beans directly as the model
portion of the application, due to the overhead of making remote
calls. In many cases, JavaBeans are returned from session beans and
used within the web tier. These JavaBeans, commonly referred to as
data transfer objects, are used within the views to build the dynamic
content.

1.5.2 The MVC View

The views
within the web tier MVC pattern typically consist of HTML and JSP
pages. HTML pages are used to serve static content, while JSP pages
can be used to serve both static and dynamic content. Most dynamic
content is generated in the web tier. However, some applications may
require client-side JavaScript. This does not interfere with or
infringe upon the MVC concept.

HTML and JSP are not the only choice for the view. You easily can
support WML, for example, instead of HTML. Because the view is
decoupled from the model, you can support multiple views, each for a
different client type, using the same model components.

1.5.3 The MVC Controller

The
controller portion of the web tier MVC design generally is a Java
servlet. The controller in a web tier application performs the
following duties:

1. Intercepts HTTP requests from a client

2. Translates each request into a specific business operation to perform

3. Either invokes the business operation itself or delegates it to a
   handler

4. Helps to select the next view to display to the client

5. Returns the view to the client

The Front Controller
pattern, which is part of the Java 2 Platform, Enterprise Edition
(J2EE) Design Patterns (found at http://java.sun.com/blueprints/patterns/indexl),
describes how a web tier controller should be implemented. Because
all client requests and responses go through the controller, there is
a centralized point of control for the web application. This helps
when adding new functionality. Code that would normally need to be
put in every JSP page can be put in the controller servlet, which
processes all the requests. The controller also helps to decouple the
presentation components (views) from the business operations, further
aiding development.