MVC Architecture

MVC architecture represents a multi-tiered approach to application implementation. The MVC architecture accomplishes this task by separating application implementation into three distinct layers: presentation, application workflow and business logic, and data store.

The Model in MVC represents the data model. Data models are usually implemented as tables within a relational database or Entity EJBs. View represents the client presentation components, usually implemented as JSP, servlets, JSP tag libraries, HTML, XML, or WML pages. Controller represents implementation of the business logic and application workflow logic responsible for the allocation of resources available to the application. Control logic is usually implemented as servlets, JavaBeans, and Session EJBs.

This layered approached allows decoupling or separation of application functional areas; that is, any changes made within one layer don't necessarily affect implementations within other layers. For example, presentation components may be updated without the need to reimplement any controller logic. Routine updates within the data model don't necessarily affect current presentation components. This paradigm also yields a natural division of labor that enables developers to concentrate on one area of expertise. Presentation can concentrate on presentation issues and no longer be concerned with business logic or data modeling details. Process or control logic developers aren't bogged down with data modeling or presentation details. Database specialists need not concern themselves with workflow or presentation details. This decoupling allows decentralized development with a higher degree of specialization in component implementation.

The J2EE infrastructure implements a MVC design pattern. Let's look at some commonly used design implementations within individual MVC layers.

View Layer Implementations

Java handlers or helper classes are commonly used to implement presentation components. These helper classes and handlers are Java objects such as JavaBeans or JSP tag libraries. These objects are usually implemented within the context of JSP pages, as shown in Figure 16.1.

JavaBeans and JSP tag libraries abstract logic (Java code) away from the presentation (HTML, WML, XML) code, supporting the MVC theme of little or no business logic within presentation components. JavaBeans are discussed later in this chapter. JSP tag libraries are discussed in Chapters 17, “Using JSP Tag Libraries,” and 18, “Creating JSP Tag Libraries.”

Controller Layer Implementations

The implementation of front controllers and dispatchers is a commonly used model within the Controller layer, as shown at Figure 16.2,. Within this paradigm, presentation components—which are usually JSPs, but servlets are often used—issue requests to front controllers. The front controllers then dispatch requests to the applicable business component for processing. These business components are Java objects, which can be Session EJBs, Entity EJBs, JavaBeans, or generic Java objects. The controller receives the responses and redirects the required response to presentation components. Controllers are usually implemented as servlets, as shown in Figure 16.2.

However, JSP controller implementations are common. The servlet's built-in request/response mechanism (which is shared by JSPs) facilitates this paradigm.

Model Layer Implementations

The Model Layer implementation that supports efficient access to data archives, both relational database and legacy systems, is the value (or transfer) object, as shown in Figure 16.1. Remote method calls are costly in terms of transfer overhead because of serialization and deserialization. The value object, which represents a complete row of a relational database table, reduces this overhead by making one method call, as opposed to the many small method calls usually needed to retrieve EJB attributes (that is, the individual fields within the database table row). Instead of making individual EJB method calls to retrieve individual attributes (database table fields), essentially one EJB method call is made that creates the value object (database table row). The value object is populated locally (that is, on the server side) within the EJB, and then transferred back to the presentation component (the client side), where individual attributes are dereferenced as needed. One remote method call is made versus many remote method calls. Value objects are usually implemented as JavaBeans. For further details about these and other J2EE design patterns, refer to the Sun documentation site at http://java.sun.com/blueprints/patterns/catalog.html.