The Model-View-Controller pattern has been a staple of application architecture ever since Graphical User Interfaces were invented at Xerox PARC. The pattern itself was invented by Trygve Reenskaug. The pattern was adapted in the mid-90s to support web applications (this adaptation became known as MVC2 in the Java World).
This adapted pattern lacked the ability to update the view from the controller, typically the user had to refresh the page to see updates to its content. The reason being that there was server-to-client connection. With the advent of Ajaxian Framework, this connection can now be emulated. Prototype, the most popular Ajax framework in 2006, was developed without MVC in mind, simply offering a remoting framework and a simpler dom manipulation. In this case, developers can choose whichever way they implement the MVC pattern including MVC2. Other frameworks like JSF/Ajax4JSF and Ruby on Rails are a lot more prescriptive in terms of how MVC is implemented.
Nolan Wright thinks server-assisted MVC implementations are a thing of the past:
MVC-based frameworks are simply unable by design to take advantage of the full power of Ajax and DHTML [even though] many of [these frameworks] have added support for Ajax (e.g., JBoss Seam via JSF/Ajax4JSF and Ruby on Rails). They force an almost airtight coupling between the user interface and the server, whereas Ajax enables a near-100% decoupling of the user interface and the server.
Therefore, we must take a step back and a look at the problem of web development with a fresh perspective.
Jeff Haynie agrees:
Refactoring allows us to continue tweaking something to make it better - and often you get incrementally better improvements. But, sometimes, when you take a step back, you’re looking at a big hairball of a design. That’s where we are with web architecture these days - and why I believe lighter-weight frameworks like Ruby on Rails have been wildly successful.
Try to do a simple web app in Java these days - name your framework? Arghhh. Puck. XML config files, web flows, JSPs, controllers, models and DAOs, WAR files, JARs, blah blah blah. And want to refactor your layout? Forget about it.
Enough is enough. We need to really rethink MVC on the server side as a way of building Rich Internet Applications.
Nolan and Jeff think that SOA is part of the solution:
Let’s take the opportunity to actually do service-oriented architecture (SOA). SOA shouldn’t just be a webservices bolt-on. It’s not an afterthought - or yet another set of crap in the middleware stack. No, it’s central to the design - it’s the main act.
Nolan offer a new foundation SOUIs (Service Oriented User Interfaces) based on Services, Ajax and DHTML:
Ajax and DHTML are highly complementary technologies - when combined they enable the creation of web applications that can surpass the capabilities of today’s desktop applications. As a result, a next-generation Web SDK is needed - one that seamlessly integrates Ajax and DHTML.
Nolan explains that it is perfectly ok to have the controllers deployed in the browser:
With one message, you can hide 3 HTML elements, show another, and send a service request – pretty cool.
Nolan sees many advantages:
- Since SOUIs talk to services using lightweight messages, services can now be written in any programming language. In other words, a SOUI is programming language-agnostic. You can change your server programming language without changing a single line of SOUI code.
- You create a simple message-based contract between the SOUI and its services. The result is a near-complete decoupling of the client and server; they are linked only by a lightweight message contract.
- You can create client-only prototypes that are fully functional since they can use local mock message handlers. The SOUI does not know the difference between using a mock message handler and using a service. [Just switch the message handler with the real service when you are ready]
Jeff concludes:
Let’s get back to simple. Let’s get back to what really matters - creating applications. Enough of the complicated server architecture.