Web development

Up until my current project which uses GWT to develop a rich web client, I always followed the best practices in terms of Web development. I used to develop thin and dumb client view (e.g. jsp) which were fed and render based on data model objects and eventually sent back to the web client.

All web requests are taken care by some dedicated controller (or action in Struts parlance) that are responsible in analyzing the user request, delegating the request to the service layer (the core of the application where business rules usually sits), obtaining the return domain object from the service and preparing the response by selecting the proper view to be rendered and sent to client. Ok, that is a very brief and incomplete description of the MVC pattern adapted to the Web server and HTTP protocol. Although this design pattern may be overkill for smaller applications, the advantages (e.g. makes web applications that are easier to maintain and are logicially divided into layers that are inherently decoupled and whose focus are on very different software concern) usually outweight the additional learning curve and relative complexity.

A great deal of coding must be done on the controller aspect of the MVC. And a lot of this includes details originating from handling the request/response of the stateless HTTP protocol...which has very little to do with the main application business logic. If I'd have the choice, I'd rather spend this time developing and improving the business objects domain, the related business rules logic and the database model, i.e. my preferred subjects and expertise!


With the advent of AJAX Web 2.0 fat client, a great deal of the weight that used to sit on the web server shoulder implementing this MVC pattern has now moved toward the client sitting on the other side of the communication channel. Web clients now make asynchronous RPC (remote procedure call) to the server without having to deal with the of HTTP concern details (for example the RPC mechanism of the GWT API isolates client code these). They can also now handle their own session state by keeping and handling the data model locally.

The server can focus less on the "C" of the MVC, and more on the service core layer designed to enforce and apply all business rules logic. The client code can choose to implement the traditional MVC pattern, when its complexity justifies it.

In my current project, all web controller codes disappeared and my web application does not move anymore from one page to another (following subsequent user request), but rather change its unique page appearance (by replacing/changing section of page through DOM manipulation) followed by user action and RPC response from the server.

My next post will present the way I've implemented my RPC client code to talk directly to my service layer using the Spring Framework. Now, I need to get back to work!

Martin