This post originated from an RSS feed registered with Java Buzz
by Scott Delap.
Original Post: Domain Objects as Data Transfer Objects
Feed Title: ClientJava.com
Feed URL: http://www.clientjava.com/archives/wireless_mobile.rdf
Feed Description: Client/Desktop Related Java Development
This commentary on Domain Objects and DTO's makes several points that should be considered from the rich client perspective as well. The developer is considering the case of a J2EE based application with the UI served from a web application on another machine. With this setup data must be serialized and moved from one machine to another the same way a rich client application would serialized data requested from a server to the client. One point made is there can be flexibility in refactoring having a DTO layer that leverages your Domain Objects. The author does point out that major structural changes (the addition of new fields for instance) will require DTO modifications as well though. Another point raised is that compromises from a client perspective don't have to trickle down to your Domain Objects if you have a DTO layer. Finally, I think the point of unusable methods on Domain Objects is the most critical one to ponder. Especially today in our lazy loading Hibernate enabled world, a key problem to solve is fetching all the objects in the object graph at the right time. The moment you serialize an object and ship it across the wire, you've lost the ability to fetch other associations it has automatically as needed. With rich clients, decisions must be made in advance about how much data to retrieve. Otherwise, you have to write your own code to populate such lazy loaded associations at a later time.
I'm not sure there is a magic bullet with this issue of development. On one hand it is nice to just create some domain objects, a persistence mechanism, and ship them across the network when needed. On the other hand the flexibility gained by having an intelligent well designed DTO layer can also be very useful.
...I've been thinking not use Data Transfer Objects (DTOs) with this. I got this idea that maybe DTOs are not needed at all when reading "Hibernate In Action". The Hibernate guys told me in the book that I could use my domain objects as DTOs instead. I could just make some of the domain classes Serializable and move them across the wire from the business tier to the presentation tier. Then I could modify the objects within the presentation according to the user's gestures and after that move the object graph back to the business tier and have my changes persisted to the database. But how well will this work in practice?...
Previous Topic
