Time to Rethink MVC on the Web

Typical web applications don't do a very good job at separating the model, view, and controller logic. The view is particularly confusing as logic is split between server side and client side. This is a side effect from trying to support "dumb" (or nearly dumb) clients (browsers that only support static HTML). Furthermore, logic that would be more appropriate in the model, often gets put into the controller to avoid unnecessary access to the database.

While these design decisions lead to faster web application servers, they also lead to what I call coincidence coding - an unwanted code separation that has no documentation or declared interface. The worst part is that this separation often happens in the most visible part of the system: over HTTP and SQL. This prevents the system from becoming a block box utility, because the internals rear their ugly heads. Any attempt to standardize the protocol (or to use well documented services) is impossible because the protocols get stuck between various components of the view or model and cannot be separated cleanly and maintained across versions.

It is not all doom and gloom: the web is a different place then it was when many of these web frameworks were designed. I am pleased to report that all modern desktop web browsers have good support for client side templating using XSLT (finally!). This means web applications today don't need to support these dumb clients. Furthermore, web proxies have also been improving enough that it is now common for production deployments to plan on use a proxy server in front of the web server(s). Accessing the persisted data is not as much of a problem as it used to be, as database caching is usually planned when systems are being designed.

With these (somewhat) recent developments, its time for a new breed of web frameworks to emerge. These frameworks could implement MVC on the web like we have never seem before - really separating the model from the view and from the controller. This could have a significant impact on the maintainability of web application software.

Yesterday, I introduced what I believe to be the first web application framework that does a decent job of separating MVC. It is called the AliBaba Metadata Server and can be downloaded from OpenRDF.org.

The view logic can only exist in static HTML, JS, CSS, and XSLT files. The model/data is transformed into standard data formats, like RDF and some forms of JSON without model specific transformations. You can't put any model logic into the controller, and all service logic must be put into the model. Stand alone, it would be slower than most web application servers, but with proxy and caching on both ends, I believe it will perform just as well and, most importantly, yield more maintainable web applications.

MVC With XSLT

When Spring MVC (Model View Controller) was first released in 2003, it helped clarify the roles and bring a clearer separation between the model, the view and the controller to Java web development. Complicated HTML pages became easier to maintain and changes were straight forward to implement. However, web applications have changed significantly since then.

With the recent explosion of new JavaScript libraries the separation between MVC has once again become blurred. Many HTML pages today are loaded in stages (a la AJAX), one entity at a time. Traditional Spring MVC seems overly complicated for small single entity results.

Creating rich AJAX web applications can still follow the MVC design pattern, although it might require stepping out of the Java/JavaScript comfort zone.

Consider a typical asynchronous request:
1) User's activity triggers an HTTP request.
2) The server processes the request and may invoke changes to the model and/or return part of the model (an entity) to the client.
3) The script that sent the request, manipulates the response and displays it for the user.

In the above we can still see the MVC pattern: the model is the server's response, the view is the manipulation of the response for display, and the controller is the server. However, this differs from the original Spring MVC of 2003 - the view has moved to the client and the model is (in part) serialized in an HTTP message body.

Part of the confusion with AJAX development is around the role of the "view". It gets blurred between the serialization of an entity model and how JavaScript displays it. Inconsistencies in this area can cause many maintainability issues as the interaction between the client and server becomes confusing.

By viewing dynamic HTTP responses as serializations of entities from a data source (model), and leaving the "view" for the client, clarity and maintainability can be achieved. The only standard display technology that works equally well for large entities and entity fragments is XSLT/HTML. Today's modern browsers all support XSLT 1.0 transformations using JavaScirpt. By using XML for the model interchange and XSLT/HTML for the view display, JavaScript usages can be limited to what it does best: filling in missing functionality of the browser.

By limiting the role of JavaScript, its reusability is maximized. In the future the amount of JavaScript required by web applications should be significantly reduced. In addition, projects like webforms2 (at google code) promise to bring tomorrow's HTML5 and Web forms 2.0 to today's browsers.

XSLT brings more flexibility and reusability to the view layer (vs JSP-like technologies). By using client-side JavaScript/XSLT with other AJAX technologies modern web applications can achieve the richness of desktop applications, while still using best practises of the MVC design pattern.