Recall from Chapter 1 that the MVC model consists of three kinds of objects: the model is the application object, the view represents the screen presentation, and the controller determines the manner in which the user interface responds to user interaction. The main benefit derived from employing this model is the way MVC decouples views and models by establishing a subscribe-notify protocol between them. A view must always reflect the model’s state. For example, if the model’s data changes, the modifications are posted back to views that are dependent on the model’s state. After receiving a notification of change, the views must update themselves.
MVC allows you to alter the way a view reacts to user input without changing its visual presentation. For example, it encapsulates the response mechanism for a controller object by enabling the principle of substitution, thereby allowing the developer to create a new controller as a variation on an existing one. This is consistent with the object-oriented concept of an interface. As long as the developer adheres to an interface’s signature, one object instance may be replaced with another object instance without altering the overall structure.
In a J2EE component-based set of interfaces, the servlet is synonymous with the MVC controller object. When the servlet receives a client request, it determines whether a JavaBean, an Enterprise JavaBean, or other object is required to fulfill the client’s request. Once this determination is made, the servlet directs a specific object to execute the business logic and encapsulate the results. Subsequently, the servlet directs a Java Server Page to deliver the content back to the client.
The MVC model is consistent with the object-oriented model. The controller component consists of servlets that mediate among various parts of the view by managing navigation and error-reporting tasks.
Traditionally, the MVC model embraces the concept of layering and divides the functionality of an application into separate vertically stacked layers. Each layer interacts only with the layer beneath it. The presentation layer objects interact with domain objects, the layer where the business logic resides. The data access layer objects access repositories at the request of a domain object. The layered structure concept was designed to incorporate a decoupled design that involves the appropriate indirection in support of layer substitution.
The MVC concept represents a component-based set of interfaces. Interfaces are designed to support the object-oriented concept of object substitution.
This layer consists of objects defined to accept user input and present application output. They include GUI objects, HTML, Java Server Pages, and servlets that act as a controller. They may also include applets, using the Abstract Windowing Toolkit (AWT) or Swing.
The MVC concept of layering incorporates the mediator design pattern. The controller object implements the mediator design pattern. (For a complete description of this pattern, refer to Design Patterns, by Gamma, Erich, et al.; Addison-Wesley, 1996.) The mediator pattern ensures that domain-specific logic is not bundled with presentation object methods, but rather is obtained from a mediator-referenced domain object. The purpose of employing the mediator pattern is to be able to define an object that encapsulates how a collection of objects interact with each other. Loose coupling is the mechanism that prevents objects from referencing each other directly. A mediator serves as an intermediary to keep objects separate. In fact, child objects only know the mediator, but not other objects. Only the mediator knows its child objects.
A servlet is a Java class that extends the functionality of a web server. The web server loads a servlet into memory where it intercepts client browser–based requests. Once the servlet parses the object, it creates a new thread and executes code within the thread. The servlet plays many interesting roles. Although the servlet is capable of generating raw HTML tags to the PrintWriter, it facilitates the production of dynamic HTML content by providing an entry point (the servlet) into the server-side Java Virtual Machine through a web server. Servlets also provide session management, user authentication, and authorization. More importantly, servlets function as an MVC controller to provide a convenient way of storing user-defined application session objects. Servlets are covered in detail a little later in the chapter.
The domain layer implements objects as standard Java classes and interacts with traditional JavaBeans. Another option exists for developers, namely, the ability to implement domain objects as Enterprise JavaBeans. The advantage here lies in making distribution easier, receiving transaction support, and facilitating object persistence.
A major obstacle facing developers is the problem of mapping data to a relational database. The added mapping layer facilitates moving data from domain objects to back-end data sources and vice versa. Although this action requires some careful planning, the developer has the option of taking advantage of the automatic services provided by a container such as WebSphere. The EJB container in WebSphere includes an intuitive user interface for supporting data persistence for EJBs.
Sun offers the JDBC (Java Database Connectivity) API for accessing data stores such as DB2, Oracle9i, and Sybase.
EJB containers perform mapping and persistence operations for storing and retrieving data. Servlets and JavaBeans may also use JDBC directly for accessing enterprise data.