MVC Patterns
One of the most common patterns in use for
developing Web applications
is the Model-View-Controller (MVC) pattern. One of
the
reasons that this design pattern is so popular is that it draws boundaries
between how data is stored and displayed. With
appropriate
boundaries, an application developer can easily alter the views, as well
as change how
data is manipulated and stored, without significantly
impacting the other areas of the application.
As the general MVC diagram shows, the view
reads the
data model and displays it in some way. A view is often
represented by HTML files.
Events that occur on the view, such as a form submission, are processed
by the controller. The
controller directly influences the
application; the controller is where application and business logic
reside. Use the controller to complete multiple tasks
with the data, such as validate input, update the data that is
stored in the model, and refresh the view
with new data, such as updated status. The model is
the data
in some representation, such as a hash table, a list, a database table,
or
any other data structure you might use.
MVC from the JavaTM Platform, Enterprise Edition (Java EE) perspective
The MVC pattern is the foundation of the Java
2 Platform, Enterprise Edition (J2EE)
application. Multiple frameworks exist that have been
developed in Java technology that make it easy to apply this design
pattern to
development. The following two common patterns exist:
1.) Apache Struts and Tiles
2.) JavaServer Faces (JSF)
While both patterns differ considerably in how you
implement MVC J2EE applications, they share one common
design point, the controller runs on the server side as
a Java service, such as a servlet. Generally, no matter
how you implement your MVC J2EE application, you have an architecture
similar to the following diagram.
Your server handles all the event
processing, view updating, model updating, and so on. For
large multiuser applications, it is possible to use a large
portion of your server CPU just processing basic events and sending
back new HTML views of the data to the browser. The more events
your application handles, the increased server load either
lowers the performance of your application or requires an upgrade of
the server hardware to contain the load. With the growth of the
popularity of applications and toolkits based on the
Asynchronous JavaScriptTM and XML (Ajax)
development style, a third method can be used to
alleviate the load on servers. With Ajax toolkits such as the
Dojo Toolkit, you can move your controller out of the server and leave
the event processing to the browser.
MVC for Ajax when using the Dojo Toolkit
While the Dojo Toolkit can be used in traditional
J2EE for MVC ways, doing so does not leverage the full potential of the
toolkit. With the Dojo Toolkit, the controller can be built
directly into the code that runs in the client browser. When
this approach is taken with the Dojo Toolkit, the MVC client and server
separation changes. This change is depicted in the following
diagram.
Advantages to using the Dojo Toolkit
to implement MVC patterns
Taking this approach to building an MVC-based
application provides several distinct advantages over the current J2EE
frameworks for MVC. The primary advantage is that rendering and
data presentation work is offloaded from the server to the
client. Your server spends less time doing the
basics of identifying positions and appropriate HTML constructs for
the browser client and can dedicate that time to processing the
data.
The second advantage to moving the controller into
the client is that you can get more client and server independence. If the
client-side controller uses simple HTTP and Representational State
Transfer (REST) pattern services for
accessing the data model, then the server-side service can be
implemented in a variety of technologies.
For example, if you
want to prototype a new application to present to your management,
you use HyperText Preprocessor (PHP)
technologies to mock up the server-side data interfaces that the
client calls for data presentation and manipulation. Now consider the situation where the application prototype is
accepted, but management requires that your application must run inside a J2EE application server and not a PHP server.
Since you kept your display and interaction logic all in the client code, you can reuse all your client code and controllers with little to no
modifications. All you have to implement to run in as a J2EE application server version are the service and data interfaces. You gain productivity
in development by having a design that is more flexible than locking into a particular server-side technology.
The third advantage is you can use this pattern to
eliminate some communication to the server. Consider the
situation where some user action in your MVC application updates
a view, such as sorting the data in the view. In a typical MVC
case, a click sends an event to the server,
the controller in the server performs some action of sorting, then
sends the sorted data back to the client, where the view is
refreshed. The click event did not change any of the data, just
how
the data is viewed. The typical MVC process required a
trip to the server, which is costly. By having the
controller running in the client, you can perform sorts and view
rearrangements without ever going to the server. Not only does
this approach reduce network usage, it makes your application more
responsive to
the user. Therefore, in those types of view-manipulation
situations, having the controller running in the client is an advantage for both
performance and user experience.
The fourth advantage is that this pattern supports a more reusable design for the data access
and the user interface aspects of your application. Consider the concepts of
Service-Oriented Architecture (SOA). The goal is to build
reusable services and not monolithic
applications. By leaving the rendering to the clients and
focusing the server on
handling the data interfaces, you are automatically following the SOA
design pattern. By using the Dojo Toolkit to build your
controllers and custom widgets, those controllers or custom user
interface widgets can be reused across multiple applications.
A fifth advantage to the Dojo Toolkit that is that
it is not browser sensitive. In Web applications that
use JavaServer Pages (JSP) files, JavaServer Faces (JSF) files, Apache Struts and Tiles,
Cascading Style Sheets (CSS), and so on, errors are encountered with specific versions of different browsers.
Pages that render correctly in
Microsoft Internet Explorer might not render correctly
in Firefox or
Mozilla. In the case of XMLHttpRequest (XHR)
communications, the
cornerstone of Ajax, the way each of these browsers achieves the
communication is different. The Dojo Toolkit provides a
layer above the browsers to filter the
idiosyncrasies of the various browsers and present a common behavior.
Instead of you having to code
around specific browser errors to get your Ajax-based MVC application
working, the
toolkit and its stock widgets generally contain the work for
you. You do not have to perform
browser checks into every page to determine how to render elements of your MVC application on a specific browser.
Disadvantages to using the Dojo
Toolkit and Ajax to implement MVC patterns
As the first advantage notes, you can offload
rendering and layout to the client. However, offloading does not
necessarily
mean that switching to this model improves performance overall.
The communication between the
client-side controller and the server-side data model must be
examined. Depending on how much data communication the
client-side
controller has to make with the server-side data model and services,
you can increase overall data traffic between the server and client,
which might negate the performance benefit gained by offloading the
controller.