2 DTO or not 2 DTO

Since the new project began I've been think about this over and over again reading as many posts and taking ideas from different posts and blogs. The more I read, the less I knew. Below is a collection of few links I've come across which have some conclusive and non-conclusive decisions/arguments, some of these post lean towards POJO's and some towards DTO. Frankly I was not been able to convince myself on what to use. (Leaning more towards POJO's as detached objects).




Here is a small tutorial talking about how to develop using POJO's. Makes you think the non-EJB2 way. (Reading this is strongly recommended)
Part 1 - http://www.developer.com/java/ejb/article.php/3590731
Part 2 - http://www.developer.com/java/ejb/article.php/3592341
Part 3 - http://www.developer.com/java/ejb/article.php/3594121

Since EJB3 is more revolutionary and uses POJO's unlike remoting in EJB2, here is a link from the sun java forums

I strongly recommend everyone to read these articles before choosing. My brains had been deep fried already reading these before trying to reach any conclusion. I wanted some other heads to think about these issues and post in their opinions.

Some points where I played the devil's advocate and jotted my concerns with arguments before we said 'I do' to DTO or POJO.
ProDTO: DTO will shield the UI if there are any model changes
Argument: Either ways we'll have to modify the DTO, the marshaller/unmarshaller to propagate these changes from the POJO to DTO. DTO does not eliminate the problem completely, but obfuscates or hides it.

ProDTO: Our service layer shall talk to various 'services' webUI or web Service or RMI or Star Trek, so we need DTOs to provide loose coupling and don't want the service to expose the domain object directly.
Argument: We will use XML (WSDL or SOAP or RestFUL or ) for data transfer, which will involve marshalling/unmarshalling of the XML to DTO and then POJO & vice-versa, any changes will again have to propagated. through all the layers. We are just exposing the POJO to the XML transformer, not the DAO calls. The POJO by itself cannot persist if in a detached state. Unless we have a usecase of just exposing half the object to the webservice (do we have a usecase?)

ProPOJO: Less effort, lean and clean design, any changes will propagate at multiple places and will provide less points of transformation errors.
Argument: The inner implementation of the POJO with the Data model needs to be changed, but the view/web service does not have to change the implementation. We have to make the changes in these layers even if we don't have to, there by adding more work and complexity.

ProPOJO: No over head of transforming POJO to DTO and vice-versa. Less memory consumption.
Argument: It's a good practice to separate your business objects and data objects, provides better decoupling.

Anti-POJO: Handling Lazy Initialization of hierarchical objects, no openSessionInView Filter for ExtJS.
Anti-DTO: Locking of objects for optimistic locking. DTO's are not aware of the revision.

Conclusion: Use POJOs as detached objects where basic CRUD calls are required and for fetching objects with minimum hierarchy, but if you need to fetch loads of info from different tables with a very small subset of columns from each, then use HQL + DTO
Select new com.vtech.model.dto.CompanyEmployee(bla bla bla);

1 comment:

Anonymous said...

A great blog. On the point about Open Session In View you can scope the transaction/orm to a fa├žade which encapsulates knowledge of what needs to be queried, lazy loaded, merged for the UI rendering phase.
I was reading some post over at http://blog.xebia.com/2009/05/11/jpa-implementation-patterns-service-facades-and-data-transfers-objects/comment-page-1/#comment-92513 which point back here.
One of the points made over there is about Chapter 6 of Clean Code. It makes the distinction between data structures (public getter/setter or public fields aka VO) verses objects that have good encapsulation such that you cannot work out or come rely upon their internal fields.
You make the good point that if your app is mostly a database CRUD application then an exposed domain model is a good fit. If your app is a complex pricing engine that needs data from lots of tables to be supplied from a remote client then most likely a DTO model may be a good fit to hide the details (else surely use something like xml to model a command object).
The nature of the client of your services can also influence the choice. If your writing a Swing app or using the ZK RIA ajax framework then your are exposing your domain model to trusted client code. If you are doing DWR or Flex or some other web remoting to user browsers then you may want to be more secure than exposing all your domain object properties to the client.