The MVC architectural pattern is not directly related to web applications. 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.
As an example, say you want to integrate security into your web site. Your first page, in this case, usually is a login screen that collects and validates the username and password. This page then directs the user to another screen that allows her to continue in a secure manner. However, as there is nothing to prevent the user from going directly to a page, each page (in a non-MVC world) needs to be aware of security. This can be accomplished by including a security check on every page, but that can be unwieldy, especially if there are some pages that need to be secure and some that do not. In the MVC world, the security is put inside the controller object. Because the interface to the customer is driven through the controller object, there is a single entry point and a single location for the security checks to be performed.
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 B2C and B2B 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.
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 or value objects, are used within the views to build the dynamic content.
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.
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/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.