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.
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. 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.
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.
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
mapping (ORM) framework such as
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.
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.
Intercepts HTTP requests from a client
Translates each request into a specific business operation to perform
Either invokes the business operation itself or delegates it to a handler
Helps to select the next view to display to the client
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/index.html), 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.
 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.