E-mail    Print    Discuss    Blog

Beyond MVC: A New Look at the Servlet Infrastructure

This article is the first of two that examine in depth the origins of the Model-View-Controller (MVC) design pattern and its misapplication to servlet framework architectures. The purpose of this first piece is threefold. First, it attempts to provide an accurate description of the problems brought about by MVC in servlet middleware. Second, it suggests techniques and strategies for coming up with a new design, one better suited to the needs of servlet infrastructure developers. Third, it offers an example of a completely new, nonderivative pattern we might use moving forward. The second article backs up my assertions by introducing and exploring a reference implementation of the new design.

Ultimately, my goal with these two articles is to convince the servlet middleware community once and for all to put the dark days of MVC behind us and to lay the groundwork for completely new, nonderivative servlet middleware architectures that better address our common needs. Please bear with me; I wouldn't write a piece about MVC in the servlet tier unless I believed it was a funeral dirge.

Part One: History of the MVC Pattern

We begin with a historical account of MVC's origins in the early 1970s and its subsequent use as a pattern for thick-client UI component frameworks.

Tracing the historical origins of the Model-View-Controller pattern is not a difficult thing to do. The man who brought us MVC has published historical documents that date back to 1973, when object-oriented programming was still being conceived and scientists were only beginning to explore the concepts of "distributed, communicating components." (See Reenskaug, Trygve, "The History of MVC.")

Following the paper trail back to the early days of object modeling is instructional in two ways. First, it serves as a reminder that the problems we face today in distributed computing are by and large the same ones faced by computer scientists from three decades ago — in other words, the proverbial wheel is still in dire need of reinvention. Second, it shows us how much we still have to learn about simplifying complex systems.

Oslo Norway, 1973

In August of 1973, Dr. Trygve Reenskaug, while working for the Central Institute for Industrial Research in Oslo Norway, wrote a paper called "Administrative Control in the Shipyard," which he presented at the first International Conference on Computing Applications in Shipbuilding that autumn. In his paper, Reenskaug analyzed the modern shipyard as an information system. In this exercise, he identified many of the technical and social complexities inherent in shipyards and suggested several techniques that could be used while describing the system. His goal was to reduce the overall complexity so the shipyard could be more easily modeled in a computer application.

If the goal of a component framework is to reduce complexity for developers modeling an information system, what strategies can the framework designer use to make this possible? Early on, Reenskaug touches upon the idea of "distributed, communicating components." His strategy is that the "total system will be decomposed into a number of components" (emphasis his; see Reenskaug, Trygve, "Administrative Control in the Shipyard"). Decomposition of a large or complex system into modular components played a central role in his strategy. By now, most of us understand this concept very well. We call it the "Separation of Concerns" of architectural components.

Following this strategy, Reenskaug begins to describe "a general framework" whose "main purpose is to enable us to mold a new information system to fit an existing way of organizing things, the resulting system being sufficiently flexible to be easily adapted to changes in the organization." (ibid.; emphasis mine.)

He then outlined several "major requirements [of] systems developed within the framework." (ibid) The following behaviors are those that the framework should seek to enable:

1. We want to build man-machine systems. Manual override on automatically produced results must be a routine matter, and the systems must be able to compute the consequences of such overrides.

2. Responsibility, authority, and competence will be spread out among groups of people in the shipyard. Our total data processing system must be divided into subsystems that are attached to the various areas of responsibility. The subsystems shall be controlled by these groups and further developed by them.

3. A subsystem must be transparent to its responsibility group, so that its owners may fully understand their system's behavior.

4. All subsystems must be open-ended, so that they may be attached to other subsystems belonging to the same or other responsibility groups.

5. The total system must be capable of continuous growth; it must be possible to add new subsystems or change old ones without disturbing the total system. It must be possible to include "foreign" systems developed by other people without upsetting the total system. The painful transition from one "generation" to the next can no longer be tolerated. (ibid.)

A condensed list of these requirements would read:

1. Simplified manual override.
2. Divisible into modular subsystems.
3. Behavioral transparency of subsystems.
4. Subsystem modules are pluggable.
5. The total system is capable of continuous growth.

Despite the solid foundation that Dr. Reenskaug had laid out for implementing his framework, the lack of an object-oriented programming language stalled progress on what was to become MVC. It wasn't until several years later, in California, that he got access to the world's "first personal computer, the ALTO, with its powerful direct manipulation interfaces." It was at this time that he began experimenting "with tools for end users manipulating their part of a total plan." (see "The History of MVC")

Xerox Palo Alto Research Center, 1978

This experimentation took place at the Xerox Palo Alto Research Center (PARC). Access to the ALTO helped Dr. Reenskaug identify the end user of a distributed system. Dr. Reenskaug and his colleagues devised "MVC as a solution to controlling a large and complex data set." Their task was similar to the task he'd defined for the component framework in 1973 — to reduce the complexity inherent in presenting an interface to the system. This time, the "subsystem" was actually the user interface.

Describing a new framework for accomplishing this task was not easy — it never is. "The hardest part was to hit upon good names for the different architectural components," Reenskaug writes. "Model-View-Editor was the first set," In his "Thing-Model-View-Editor" paper (see Reenskaug, Trygve, "Thing-Model-View-Editor"), Dr. Reenskaug defines the following terms:

1. Thing: "Something that is of interest to the user." (A real-world concept.)
2. Model: "An active representation of an abstraction in the form of data in a computing system." (Abstraction of the Thing.)
3. View: "One or more pictorial representations of the model."
4. Editor: "An interface between a user and one or more Views." (Later called "Controller" and "Tool.")

Out of these early prototypes, MVC Triads emerged in SmallTalk-80. The model was an abstraction of the real-world concept, the view was its visual representation, and the controller was the buttons and slider bars that allowed the user to interact with it (thereby "controlling" the view). All pieces in the triad were interconnected and could communicate with the other two pieces, so there was no layering or abstraction involved. Since then, Reenskaug has "preferred to use the term Tool rather then Controller." According to his notes, these are the terms he has used in later implementations (see "The History of MVC")

Shortly thereafter, Dr. Reenskaug left the PARC laboratories and his work was carried on by Jim Althoff and Dan Ingalls. Because of this early work, UI Development in ST-80 was greatly simplified, and the MVC pattern continues to this day to be an effective and appropriate solution for the design of user interface components.

MVC Pattern Language

It is important while we are studying and using MVC that we bear in mind the original purpose of the pattern: to reduce the complexity of user interfaces for a large and complex information system. It was designed for a specific purpose and evolved to meet a specific need.

Dr. Reenskaug's work in MVC has not been abandoned. Earlier this year, he began publishing material on his new MVC pattern language.

Nowhere, ever, in any of his papers was it suggested that the MVC pattern could be used to address the needs of n-tiered workflow processing infrastructures. But here we are, 24 years later, trying to pound in nails with a screwdriver. Despite the careful effort of scientists from Reenskaug's generation, it seems that we've not learned a thing.

View all java.net Articles.