MVC and Layered Architectures in Java
Chapter 2 described the technologies and the application templates used to build applications with J2EE technologies. But that discussion was only the tip of the proverbial iceberg. Remember that the three major technologies we focus on are servlets, JavaBeans and Enterprise JavaBeans (EJBs), and JavaServer Pages (JSPs). Together, these three object types form the core of a powerful architecture expressed in the MVC (Model-View-Controller) design pattern.
The control flow associated with this architecture starts with the browser's request being handled by a servlet that determines which program elements—JavaBeans, EJBs, or other objects—are required to carry out the specified request. The servlet then directs them to perform the business logic and to subsequently encapsulate the results of the execution. Finally, the servlet selects a presentation template—a JSP—for delivering the content back to the client. The JSP generates a specific response by accessing the resultant content available through the JavaBean(s) and/or EJB(s) (Figure 3.1).
){kind=link}
Figure 3.1 MVC Mapping to Servlets, Components, and JSPs
This architecture provides a clean separation between the business logic implementation (Model) and the presentation (View). This separation makes it possible to independently develop, modify, and manage the implementation of the business logic and the form and style of the resulting presentation (HTML). Another layer of objects preserves the independence of the Model and the View and ties the two together. That Controller layer is made up of servlets that adapt the Model-layer objects to those needed by the View layer and mediate among various parts of the View layer by dealing with navigation and error-handling and reporting duties. The details of each of these pieces are discussed in later chapters. However, before we begin our overview of the J2EE, we need to examine the MVC notion more in depth and to discuss a few more architectural elements.
What's an MVC?
Computer scientists have an annoying tendency to overload terms, assigning multiple meanings to one word. A prime example of this, and an interesting study in how meanings change when conveyed from person to person, is the term Controller. Because we rely on an interpretation of MVC in our discussion, we need to see the alternative meaning to understand how the term is used in the Java community.
One of the central ideas of the Smalltalk-80 system was the Model-View-Controller (MVC) user interface paradigm, in which Controller had a well- defined, limited meaning. One of the best-known early public descriptions of MVC was that by [Krasner]: "Model-View-Controller (MVC) programming is the application of this three-way factoring whereby objects of different classes take over the operations related to the application domain (the Model), the display of the application's state (the View), and the user interaction with the Model and the View (the Controller)". In "classical" MVC, the Controller acted as a strategy for user interaction used by the View and the Model.
About the same time that this paper was published, in the late 1980s, Joelle Coutaz proposed another architecture. In this architecture, called Presentation-Control-Abstraction (PCA), the Presentation layer was responsible for the display of the application's state and interaction with the user—equivalent to both the View and the Controller in "classical" MVC. The Abstraction layer performed the same function as the Model layer in MVC. In between was a middle layer, termed, unfortunately, the Control layer, which acted as a mediator between parts of the Presentation layer and as a focal point for navigation.
Over the years, the division of roles in PCA has gained supporters, with presentations and reinterpretations in such books as [Jacobson 92] and [Buschmann]. However, over the same time, the PCA architecture has been increasingly referred to as the MVC architecture. We won't try to correct this reapplication of terminology but instead will go along with referring to a PCA-like architecture as MVC.
Layering
You've seen how the MVC design pattern can be used to structure applications built using J2EE technologies. Layering is a generalization of this concept. Application development is commonly accomplished in a vertical fashion, or at least the division and the estimation of work are determined by defining the application's primary user interfaces.
Underneath these interfaces, business rules, behavior, and data are obtained and manipulated, based on activity via the user interface. Architecture should provide a blueprint that will guide developers on when and how objects are defined during the development process. The importance of establishing this blueprint is realized in support of the iterative development process, whereby vertical slices of application functionality are delivered in iterations made up of planning, development, and assess- ment activities. The architecture must support both vertical and horizontal dimensions of an application. Horizontal development activities consist of applying logging, exception-handling, and start-up/shut-down mechanisms—behaviors that must be provided by all applications. Vertical activities involve implementing slices of application functionality from presentation to data source access. Having the infrastructure in place to allow development to occur in these two dimensions is the responsibility of the architecture.
Most experienced IT professionals agree that developing and adhering to an architecture are key to the success of large-scale software development, a notion validated by computer science pioneer Dijkstra in 1968. Since then, layered architectures have proved their viability in technological domains, such as hardware and networking. Today, corporate and retail computing are moving away from the desktop into a realm of distributed thin client computing.
Layering has proved itself in the operating system domain; however, the same benefits are available when applied to e-commerce or to thin client–oriented applications. Layered architectures have also proved themselves beyond the original centralized computing environments and have become essential in supporting the iterative development process by promoting reusability, scalability, and maintainability. In the following sections, we define and justify a layered architecture for J2EE.