Introduction
In this post I will analyze problems related to presentation and domain model mapping in GWT applications. I will use AMS2 as the basis of discussion but most issues are not specific to any particular application.
When developing presentation layer for any web application we have two typical options:
1) hide domain model behind some facade layer and use separate DTOs for state transfer (at the moment this option has been implemented in AMS2)
2) expose domain model and let presentation layer access it directly
Following is list of main aspects that should be considered when deciding between these two options.
Mapping client and server state
In case of exposed domain model no special mapping is needed (if ORM tool like Hibernate is used then this is not that straightforward - see ORM integration). If DTO approach is chosen then in worst case we have to manually write mapping code that copies needed parts of domain object's state into DTOs and vice versa. Fortunately there are some automation strategies that can help. In AMS2 we are currently using javabean properties copying which automates mapping of maybe 30% - 60% of all fields. Of course more advanced strategies can be implemented like using annotations on DTOs or using some existing object-to-object mapping libraries like Dozer.
Leaking domain logic into presentation
The problem currently also present in AMS2 is that some domain concepts have been "accidentally" implemented in DTOs. For example in order to make building presentation layer easier we created small library of date/time classes for out DTOs. These classes however contain quite much logic that can be considered to be part of domain behavior.
Java SDK usage constraints
The biggest problem when choosing option 2 is keeping the domain model unaffected by the constraints posed by client technology. Although latest GWT 1.5 version significantly reduces client code limitations still only part of Java SDK is supported. This means that it is practically impossible to use existing 3rd party libraries in our domain classes. For example one library that might have been quite useful for AMS2 is JodaTime. Luckily work for making this library GWT compatible has already started (http://code.google.com/p/gwittir/). However porting every needed library and keeping them up to date obviously isn't very practical.
ORM integration
Problem with exposed domain model is that if ORM tool is used then we need to do some extra work in order to remove all that persistence magic from domain objects before we can transfer them to client. Again there are some libraries that help (e.g gwt4hibernate) but this is something we need to deal with. In any case it is not possible to use Open Session In View pattern which makes exposed domain model so comfortable in traditional web applications.
UI binding
Although we can add setters/getters to domain objects that are only needed for UI binding I don't think that it is very good practice. On the other hand we are free to add anything to DTOs.
Amount of data transferred between client and server
It is harder to optimize the amount of data being transferred in case of exposed domain model. However at the moment there is no evidence that this might become a problem since it is good practice anyway to split entities which tend to have too many attributes.
Conclusion
As I said already second option has been chosen for AMS2 currently. However I don't think it is something that should never be reconsidered. Actually this is also one reason why I wanted to write this post 
At Java Server Side Conference I tried to get answer to this question from speakers who were giving sessions about RIAs. Shashank Tiwari who gave speech on Integrating JPA and Hibernate with Rich Internet Applications said that one should really try to reuse domain model objects in presentation layer since if you already have created a domain model to yourself that matches your domain then it makes sense also to use it as much as you can. I got same answer also from Jeff Dwyer who is the author of "Pro Web 2.0 Application Development with GWT". Interestingly in his tocollege-net application Jeff is using exposed domain model for displaying data but separate command objects for sending changes back to server.
You can check my post about domain and presentation model mismatch issues in case no ORM tool can be used here.
Comments (1)
Jul 11, 2008
Aleksei Rovenski says:
It seems to be the current trend. Frameworks and containers tend to take care of...It seems to be the current trend. Frameworks and containers tend to take care of such things more and more. Though I'm not sure this is the case with GWT.
Seam framework for example fully utilizes the domain approach and allows you to easily inject domain objects (or any other beans) and bind them with UI elements. The object state is stored in the DOM and is updated depending on bindings. Binded objects are send automatically on submit, but if you want to perform a custom action in some other place, you can just issue an action call (which is a service method) and pass it back the injected domain object. I think there were some annotations in this framework to restrict some properties from being exposed to UI.
This approach allows to minimize duplicate code and makes the design much more simple. I was quite impressed that even ORM validators can be reused in UI. You just use existing or write custom Hibernate validator that sets error messages, Seam automatically applies them on binded properties when they come to the server and if validation fails it looks for the place in the UI where you specified to show the error message.
In result of this approach there is basically no glue code you have to write most of the time and you can actually write applications without controllers at all. I think this is the future - frameworks completely removing glue code necessity