You can't pick up a book on modern Web presentation development without having to wade through a discussion about Xerox Parc's Model-View-Controller (MVC) design pattern. MVC is a useful interpretation of a strategy for presentation architectures and their place within the larger application architecture.
MVC was originally defined to reduce the programming effort required by applications that had to render the same information in more than one presentation format. MVC is also a good model for discussing the isolation of functional roles within any object-oriented application.
The impact of an MVC architecture addresses some of the more interesting real-world project and product issues:
Long-term application maintenance
Insulating business data generation from the display
Defining a presentation architecture that can support a variety of client types, from browsers to phones, with minimum impact to the application's overall implementation
Isolating functional roles
Figure 3.1 illustrates a generic MVC and the relationship of the model, view, and controller.
Figure 3.1 J2EE Blueprints' interpretation of Model-View-Control.
The view is responsible for interacting directly or indirectly with the client. In the case of browsers, the view is delivered as-is to the client. For J2ME, Flash 5, and other "smart clients," the view is delivered as raw data subject to display by the client display engine. The view conveys one or more events reflecting the user's intent (for example, edit, browse, delete), and any data associated with it, such as a login user name and the password, is conveyed via HTTP request. Other data that the controller will be interested in will tell you about the nature of the clientfor example, whether the client is a simple Netscape browser or a small J2ME phone.
The model is responsible for tracking and maintaining the application's state. It generates an asynchronous event when something interesting has happened, such as a change in the state of information. The model couldn't care less about what is done with the information that it provides.
The controller is the traffic cop logic that enables the view to interact with the model. The controller handles the events that put the model into edit mode, browse mode, and so on.
Applying MVC to Presentation/Publishing Technologies
Sun did a great job implementing MVC with the Java Swing API and its component-style implementation. Swing is being used as a great example of an MVC implementation for the Barracuda project, which is part of the Enhydra suite of open source projects.
But this discussion is not going to shove XMLC onto the MVC model. In fact, we're going to tell you why XMLC doesn't reflect the MVC model and why that's a good thing.
The great irony is that same company that brought us Swing is touting JSP as what is really an "MVC-ish" technology. Sun has watered down the definition and intent of MVC, moving it from a component model to a more granular discussion of moving grosser objects, such as pages, around in a largely server-side application.
This makes a lot of sense as you become familiar with JSP. As we cover JSP in this chapter, it will become clear that this is a presentation strategy that was defined with the "server-side view," where Web application programmers abound. If you've been in the industry awhile, you've probably observed that there is a large difference in orientation between server-side, operating system developers, and client-side desktop application developers. Somewhere in between, there are true client-server developers.
JSP was really defined to address the large market of server-side developers who have never really been client-server developers and therefore have little client-side experience. Embedding Java in markup language is really something that speaks to the server-side developer. It's to Sun's credit that they've been able to map a client-server-like model, MVC, onto a very server-side technology, JSP.