Introduction

Model-view-controller is a design pattern that defines a structure that works well for user interface programming. It came out of the Smalltalk community and has since been adopted by the deisgn patterns folks [link]. The basic idea of MVC is to separate the data that the user is working with (the model) from the business logic (the controller) from the presentation (the view). It's a nice idea and it works well in practice, too.

People have tried to apply MVC to web user interfaces but it's not as clean a fit. The biggest issue is that the web is stateless so there's no persistent "model", what passes for a model is the data that will get displayed on the page that the view returns to the user. So the breakdown is usually like so:

• controller: the code that catches the request from the browser and figures out what to do based on that request
• model: the data that's built by the controller and passed to the view
• view: the code and data that format the model into a purty web page and return it to the browser.

The current "best practice" recommended by Sun is called "model 2 MVC" which has three parts: the controller is implemented by a servlet; it catches the request and puts the model data into a structure which it passes to a Java Server Page which renders HTML to the browser. The components used are based on the idea that the controller will probably be coded by a programmer, who wants to write in Java, but the view will probably be written by a web deisgner, who will probably use a web page generation tool such as DreamWeaver.

Problem

This works well but has several problems. First, it requires a lot of processing on the server to do the controller preocessing and model->view transformation. Second, html is not always implemented consistently across different browsers so it's difficult to get pages which look similar on Netscape and IE. Third, it's very easy to "cheat" and end up with html in the servlet or business logic in the jsp, especially if there's no clear organizational difference between web designers and programmers. Fourth, sending HTML to the browser wastes bandwidth because the entire page must be re-sent even if one item changes. Most of the HTML content (layout tags, static text, etc) doesn't change from page to page, just some of the data in the page, however there's no way to separate the two from each other.

Modern browsers are capable of accepting XML instead of HTML, and they can apply XSLT transformations so we should be able to implement the "view" entirely in the browser. In theory this should solve all three of the issues in the previous paragraph. The issue is how to split the model, view, and controller so that each part is handled by the software component that makes the most sense.

Proposed Approach

At a high level, the MVC components look like:

• controller: implemented by a server-side technology, e.g. Servlets or CGI.
• model: the XML that the controller sends to the browser in response to a request.
• view: the XSL and CSS stylesheets that transform the XML into something that the browser can display to the user.

Controller

The controller is implemented in a dynamic server-side technology such as CGI, ASP, or Java Servlets. The emphasis should be on choosing a technology which is efficient at run-time and a good fit for your programmers. The controller should send only XML back to the browser (i.e. mime type of text/xml ) with a processing instruction telling the browser to transform the xml using a page-specific xslt transform.

Model

The model is an XML document which is sent from the controller to the browser. While the model can be any valid XML it's important to follow a few guidelines. First, the model must be pure data, no html or pseudo-html. Second, it's likely that you'll want to define a standard XML DTD for the model, as this will make it easier to build modular view data.

Each model page tells the browser how to get the view with a proceesing instruction like so:

<?xml-stylesheet type="text/xsl" href="xsl/index.xsl"?>

View

This is the fun part. Each view is composed of a page-specific XSLT stylesheet which includes section-specific or site-wide stylesheets. The views should be entirely static, i.e. there should be no need to process the view pages on the server side. This allows browsers and webservers to implement an efficient cache strategy just as they do for other static content, so typically each view should only be pulled from the server to the browser once and then kept in the browser's cache.

Discussion

Let's see how the browser-side MVC approach stacks up against the traditional approach by testing whether it solves the four problems we described above.

Problem 1 Browser-side MVC is much more efficient for the server because it moves the entire model->view transformation into the browser, allowing the server to concentrate on the things that it must do. The amount of savings will vary from application to application but should be significant.

Problem 2 It's not clear whether browser-side MVC will be a benefit here or not. It has one big drawback: it only works with relatively modern browsers, e.g. Explorer 5 or newer, Netscape 6 or newer, or Mozilla-based browsers. The good news, though, is that the browsers that support XSLT and CSS tend to support it in a much more standards-compliant way than they support HTML.

Problem 3 Because the controller sends only data (in XML format), developers can't "cheat" and blur the lines between controller and view. As long as you're sending HTML (which contains both model and view in one file) you can play games with the mechanism for generating that HTML but since the XML contains only model and no view the separation is actively enforced.

Problem 4 This is a huge advantage of browser-side MVC. Many applications have less information in the HTML page than they have style, so those applications can expect to see more than a 50% reduction in bandwidth since the style will be sent to the browser once and cached for later re-use.

Conclusion

Browser-side MVC has many substantial advantages, and only one drawback, but that drawback is severe: it works only with new web browsers. But if you're confident that your user community is using new browsers (corporate intranet applications, for example) then it's almost certainly the way to go.

-- TobyCabot - 24 Nov 2002