MVC Patterns   

  
MVC Diagram

   
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.
                                                                                                              
J2EE MVC 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.

Dojo Toolkit MVC


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.