Last week I stumbled over this interesting article on the potentially changing Model View Controller architecture implementations. (Sidenote: here's the more subtle distinction between MVC1 and MVC2 described. And here's an article on the ambiguity of the term and pattern MVC.)
An example logical diagram of MVC2 is shown below:
For quite some years, the general practice was to generate HTML as result of the View, with the browser rendering it and being the thin web client. These days though, more and more the web client is getting heavier ("fatter") because of all the Javascript being used for AJAX, SPI and, in general, more logic on the web client.
The article takes a look at the different approaches to MVC implementations:
- the HTML-only approach;
- the HTML+Javascript "basic" approach; some of the Model's "business logic" is duplicated on the client;
- the "AJAX" approach; partial views can be updated, the view consists of multiple HTML fragments, Javascript creates the View, not the application server;
- and the full-blown Javascript-only ("a la gmail") approach; Javascript in the browser creates the views, near-complete responsibility for the Model business rules in the web client (browser), the web client would be the Controller.
The approaches range from, at the one extreme end, the definitive "thin client", and at the other extreme end, the definitive "thick client"." Example frameworks that can easily facilitate the last option are
Google Web Toolkit (Java to Javascript) and
Pyjamas (Python to Javascript). Below GWT's architecture diagram is displayed. Note the (relatively) limited application server procedures, part of the Model, preferably only performing basic validation, security, etc.
The new MVC2 diagram for the above mentioned fourth approach would look something like this:
Included in the article is also how you could split up work in a team between people working on the View and Model parts.
I do not completely agree with the statement in the beginning of the article that says
"The Web client takes care of keystrokes and mouse movements: the Web browser application itself is the Controller". I'm reading this as: the browser is the controller. Though, when you look at the first picture, that is
not what the Controller is supposed to be.
But, in general the whole potential movement of going to thick clients is an interesting one to keep an eye on.
Other pros for thicker Javascript-based clients (not mentioned in the article) are:
- Easier distribution of new versions than in the old days with fat clients like Visual Basic, where you had to make sure all clients got updated;
- Easy opening up of your SOA webservices. The fat client could directly access them;
- Easier mashup possibilities at the View layer via Javascript;
- Potentially a large improvement in scalability: the client processing power is used as much as possible, the application server only performs several basic checks;
- The Javascript generator/builder takes care of browser compatability.
Several cons are though:
- Potentially quite significant longer page loading times when the Javascript all has to be loaded at once;
- If not designed correctly, there could be significant extra network traffic;
- Being dependent on the Javascript generator/builder when a browser is (not anymore) supported (though an opensource framework allows you to build it yourself if really needed).
Del.icio.us
DZone
Reddit
Digg
