Today is a good day to code

The MVC Disaster Befalling Application Servers

Posted: December 31st, 1969 | Author: | Filed under: java, Programming, Uncategorized | Tags: | No Comments »

The MVC Disaster Befalling Application Servers

Picture of IrvinI have always felt that the entire metaphor of MVC has been broken to a degree in web development. For a while I thought that AJAX held promise that eventually we would reach the point where we could have true MVC in that the controller would be the application server, the model would reside in the database, and the view would be entirely pushed down to the client as JavaScript.

Unfortunately, largely because of Google and its cohorts, this promise will have to wait. Since pages must be indexed, and Google refuses, not can't, but refuses to index AJAX content the pattern will remain broken.

The first and most egregious breakage of MVC is between the controller and the view, so we'll start there. The current implementation of web applications typically has HTML residing on the server mixed with JavaScript. This HTML is usually generated by an application server, so it is mixed with some, hopefully small, amount of business logic. Frequently this resembles a family gathering over noodles, tomato sauce, and meatballs. If people want dynamic behavior they will frequently deliver an RSS feed, or some other form of XML or JSON to the client via AJAX and update some div somewhere after parsing it. This is how good implementations are done today. What I'd like to know is where is the MVC in that design? business logic should not be allowed in template pages at all, no conditionals, no loops, definitely no method definition, this should not be allowed. What should happen is that you should be able to use an XML tag to create an instance of a bean representing a view interface and call getters. This would be a proper implementation of an application server IMHO.

The next and most dangerous breakage of MVC, not just in code cleanliness and readability, but also in security comes in the interface between the model, and controller, or as in some cases the model bypassing the controller and heading straight for the view. Typically this manifests itself in some process generating HTML, JavaScript and CSS from the domains data, and putting that content on an application server. Then using JSON or XML and the XmlHttpRequest pulling that preformatted content and putting it directly on the screen. In this case, there is no separation between layers at all, its just that kid putting his stupid hand down through the cake and squeezing at your birthday party.

If you are a single developer, it may be possible to manage such an implementation, but for a team it is impossible, there are bottlenecks everywhere, UI people have to wait for the process to run to generate the markup, the back-end people have to wade through lines and lines of markup to debug their code, and if you have AJAX engineers, forget it, they have to understand your back-end code to deal with the generated JavaScript. In other words, and put simply its a mess. Even sending HTML to the UI, a hijacker could change URLs so your client clicks and goes to a phishing site, etc… that is not to say that it couldn't happen with XML, but it is a little easier to handle these security issues if you have several steps between receiving the data and displaying / executing it.

On the security front, many people like JSON. I like it too if all hackers were to disappear. If someone were to inject packets into your JSON stream, it is too easy to hijack someone's browsing session. Remember all JSON is executed once its loaded in most cases, at least with XML usually it is treated like text and is never eval'd.

Unfortunately there is no application server that comes close to this strict MVC implementation. Maybe, in a stretch you could suggest that JSF, JSP, JSTL, and Tomcat all together create a decent MVC implementation, but really no server does that. Even if it did, people wouldn't know how to use it anyway.

Why does this matter? It doesn't if you are the only one maintaining and implementing a web application, if you waste your own time it really doesn't matter. It is when you need to scale in performance via parallelism, or in resources that you will constantly curse yourself for not fixing this broken MVC implementation. As far as I can see, facebook is coming the closest to doing a good job, at least metaphorically in this area, that may be because I can see their API. The fbml model is a good one, it conceptually separates business logic from the view, and hopefully their model is separate, I'd say it is because of the robustness of their model API it is.

At any rate, I'd hope to see better application servers, and implementations soon. I think it will take better application servers forcing better implmentations to make people change.