MVC for GWT

General idea

Since MVC is probably the most most widely used architectural pattern for designing classical web applications it is also appealing choice for GWT. However optimal implementation of this pattern differs quite significantly from traditional web MVC and is much closer to MVC for desktop clients. One of these differences is that the Model in MVC should be allowed to communicate with underlying (business) layer. This is opposed to classical web application where such responsibility is typically given to a Controller. I believe that this applies to RIAs based on other technologies as well unless they have built-in support for some other design.

I think that primary reason for this difference is that in classical web applications you have very little state in client while typical GWT application stores most of interaction state in client. In order to keep system responsive we need to be able to send only specific changes of Model's state from client to server as a response to user actions.

Example

We have an activities management applications (like AMS or Google Calendar) where user can see all activities of current week. Lets compare implementation of use case where user wants to move one activity to the next day.

If we try to apply typical web MVC to GWT application we will have following implementation:

1) browser sends new coordinates of dragged activity to CalendarController
2) CalendarController tells CalendarModel the new column of moved activity
3) CalendarModel calculated new start and end dates for moved activity
4) CalendarModel notifies CalendarController about changes in its state
5) CalendarController sends changed activity to CalendarRemoteFacade on server
6) CalendarController tells CalendarView to redraw changed activity on screen

There can be variations to above sequence but what remains is that Controller is responsible for two things: interpreting user events and synchronizing Model state with server. In case of complex UI it makes no sense to send the whole state of Model to server upon every small change. Therefor Model needs to expose its internal structure and update strategy to the Controller.

Much better solution is to let the Model send its state updates to server:

1) browser sends new coordinates of dragged activity to CalendarController
2) CalendarController tells CalendarModel the new column of moved activity
3) CalendarModel calculated new start and end dates for moved activity
4) CalendarModel sends changed activity to CalendarRemoteFacade on server
5) CalendarModel notifies CalendarController about changes in its state
6) CalendarController tells CalendarView to redraw changed activity on screen

Note that outside of CalendarModel no one is aware that there even is a server. If we want to start using local data store like GoogleGears or change update strategy we just need to modify the Model.

Summary

Although we are used to thinking of Model as simple JabaBean with nothing but bunch of getters and setters the Model in rich client application is something quite different. In fact there is nothing in original MVC pattern that would disallow Model to communicate with some lower layer to persist its state. In paper "Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller" Steve Burbeck says:

Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

My related article on GWT: Presentation and domain model mapping in GWT applications