As shown in Chapter 3, the use of Servlets allowed convenient management of events and program flow, but cumbersome ability to generate responses. Conversely in Chapter 4, the use of JSP provided excellent definition of response pages but gave maintenance concerns with scriptlets embedded in between HTML. Chapter 5 introduced beans as a way of eliminating some of that scriptlet code with easy yet powerful tags.

This chapter attempts to unite the three technologies (Servlets, JSP, and beans) by blending the best of all three approaches. This approach solves most of the above problems. When we add custom tags in later chapters, we will complete the picture.

In this chapter we will:

• Introduce the popular Model-View-Controller (MVC) architecture. In the development of Graphical User Interfaces, the MVC design pattern has emerged as a popular architecture for partitioning functionality.
• Explore the MVC architecture and apply it to our time entry system. This useful but limited example will also dramatize the importance of comprehensive frameworks such as Struts, which is discussed in depth in Chapter 21.
• Take a look at some advanced topics with Servlets and JSPs, such as HTTP Session Binding Events.
• Discuss some advanced techniques for combining Servlets and JSP, including the use of event listeners.

The Model View Controller Architecture
Originating with Smalltalk designs, the MVC pattern partitions functionality into three interacting components – the Model, the View, and the Controller. You may ask why do you care? Often it is not always apparent where in your design functionality should reside. For example, is a piece of functionality better served using a JSP, Servlet, or a bean? Writing out all of your HTML from a bean is surely not the appropriate solution, just as putting all your business logic in a JSP is not appropriate.

MVC is a design paradigm where each component easily and naturally maps to our three main implementation technologies – beans, JSP, and Servlets.

The Components of an MVC Architecture
At a simple level, the components of MVC architecture interact as shown below. The Model holds the data, the View retrieves the data and generates a dynamic display, and the Controller provides the logic processing layer and delegation to the Model and View:

Components of MVC architecture

Tying the picture to our implementation technologies results in the following architecture:

MVC architecture

Let's now look at each of the major components of the MVC design pattern in turn. We'll look at what the component provides, and how it can be organized.

The Model
The Model represents the business logic of an application. Encapsulating business rules into components facilitates testing, improves quality, and promotes reuse.

The Model can be further partitioned into State and Action components.

State Components
The State defines the current set of values of the Model and includes methods to change those values. These methods are where some of the business logic is captured.

The reusable nature of beans allows for the somewhat independent construction of the State components. As far as being protocol independent, State components should be isolated enough so they can be accessed by applications that use HTTP, RMI, etc., that is, the protocol would be another layer on top of the component. Their construction should take into account current requirements and consider future growth and evolution. This independent construction facilitates sound design in these ways:

• Reuse Elimination of presentation logic allows different applications (for different audiences or using different technology) to make use of the same business logic.
• Quality By putting the business logic in one place, it can be reviewed and tested more thoroughly. Contrast this approach with the cost and less stringent test coverage if the business logic were embedded in each application that needs it.
• Robustness The business logic is more easily enforced. Encapsulating the logic in one place can encourage its reuse, reducing room for errors to creep into the logic. For example, if every designer of a series of related applications (say time entry, expense reports, project budget requests, and salary planning) used the same Approval bean to route cost-related items (such as a time sheet charges to project budgets, expense reports for business trips, funding requests for pilot projects, and raise requests), the same business logic would be enforced across the entire suite of applications.

Action Components
The Actions define the allowable changes to the State in response to events. Business logic also dictates the construction of Action components.

In implementing the Action components, the choices get more complex. In simple systems, the Actions may actually get absorbed into the Controller, but this is generally not recommended. Typically a layer of Action beans is created to capture the requirements that govern interaction with the State components. As far as our time entry system, the 'Summary' action represents an example of an Action component.

Often Action components must be aware of the protocol in order to obtain information about the event. This is a dangerous situation, as it ties business logic to a specific protocol, limiting potential reuse.

Some simple rules of thumb are helpful when constructing your Action components. Adapt and add to this list for your particular set of requirements:

• Take a passive approach to Action components, only handling what each absolutely needs to handle. Create more State components if you need them. The Controller will manage all events and invoke the appropriate calls to Action methods.
• Partition the business logic to keep it separate from the implementation protocol (ideally in separate beans). As this book is focused on the HTTP browser based protocols, consider partitioning the use of resources from javax.servlet.* and javax.servlet.http.* packages into a separate layer from business rules (say, via an adapter design pattern). This allows the business rules to be reused in other architectures such as a GUI based and non- servlet architectures such as RMI or CORBA.

The View
The View represents the presentation logic of an application. The View components obtain the current state of the system from the Model and provide the user interface for the specific protocol involved. For the focus of this book, the protocol we are interested in is HTTP browser based systems.

As part of the generation of the user interface, the View is responsible for presenting the specific set of events that the user may enact at any given moment.