Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

When to use DTOs and not serialize mapped POJOs...

 
hernan silberman
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm working on a project using Hibernate and our biggest technical hurdle was building code to construct Data Transfer Objects based on one or more of our mapped Domain Object Model classes. Both JDO and Hibernate claim that this simply isn't necessary because you can "detach" persistent instances and they become your DTOs or value objects. This is true in theory, but has proven ugly in practice:

* Detatched JDO instances are instrumented by the JDO compiler. Code on the client side might call a public method that accesses a lazy unitialized collection and all hell breaks loose. You could defend against this problem by forcing all lazy references to load, but you might end up with a massive object graph, if your schema and mappings are good. Plus, you have to include jdo.jar on the client (ugly).

* Detatched Hibernate instances have the same problem, except they're instrumented at runtime. Again, you could defend against this problem by forcing all lazy references to load, but you might end up with a massive object graph, if your schema and mappings are good. Plus, you have to include hibernateX.jar on the client (ugly).

* The API on our DOM instances were rarely the APIs we wanted to expose on the client side. Data hiding was important and it confuses developers to have a public API they're not supposed to use on the client side. Plus, this couples the client and the server too much. We became squeamish when we realized how much responsibility we were putting into a single class. Often in our object model, a DTO was built using pieces of several domain objects.

Anyhow, it was clear fairly early that we had to use DTOs on our project and that this is a design decision everyone will have to make for themselves. Overall, our experience with both Hibernate and JDO have been extremely positive. I just thought I'd point out that both JDO (Solarmetric) and Hibernate docs are a bit overly-positive about not needing to build special code for DTOs. This is common sense for a seasoned application developer: DTOs/value objects are still an important pattern to understand, even with Hibernate or JDO.

thanks...
Hernan
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

* Detatched Hibernate instances have the same problem, except they're instrumented at runtime. Again, you could defend against this problem by forcing all lazy references to load, but you might end up with a massive object graph, if your schema and mappings are good. Plus, you have to include hibernateX.jar on the client (ugly).


You can use multiple strategies for this: use a hierarchy of classes the upper level containing only the directly fetched info (no relations). Another option where using DTOs is to involve some JavaBean mapping tools (BeanUtils for example).

Plus, this couples the client and the server too much.


It is a normal thing that the client and server have access at the same domain model objects (again my 2cent).
[ August 31, 2004: Message edited by: Ali Pope ]
 
hernan silberman
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use multiple strategies for this: use a hierarchy of classes the upper level containing only the directly fetched info (no relations). Another option where using DTOs is to involve some JavaBean mapping tools (BeanUtils for example).


In our case, using BeanUtils proved to be the most flexible option. This allowed us to have a very nice Domain Object Model on the server that we could tune in fine fashion and also gave us the flexibility to decide exactly what collection of data, from exactly which domain objects, needed to be sent to a client for them to successfully complete a use case. This is the power of data transfer objects.

The highly connected objects in a typical Domain Object Model generally make poor data transfer objects, they're designed with different goals. Using class inheritance to separate autofetch/lazy fetch class attributes is interesting, but seems like a strange reason to subclass.

This is really an application-specific issue, and I can imagine some projects where serialized DOM instances would work fine. I have to imagine that the typical enterprise application would benefit from thinking carefully about Data Transfer Objects.

More on the topic:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

hernan
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In our case, using BeanUtils proved to be the most flexible option.


I am happy that you found this solution too.

[...]but seems like a strange reason to subclass.


In fact I think it is a good solution (for example consider a TABLE with 200 rows). I think its preferable to use inheritance rather to have to hand write the only 25 needed fields.
 
Gavin King
author
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, when you use DTOs, you actually need to write two things:

(1) the data transfer model (which usually looks very similar to the domain model)
(2) the assembly logic, which defines exactly what data i need to put in the DTO for each request to the server

Now, if you ask yourself what a DTO for a POJO looks like, well, it usually looks exactly like the POJO itself. So step (1) is really redundant, most of the time.

However, if you use Hibernate or something similar you certainly still need to write the assembly logic somewhere, and I think that really answers your first objection.

Your second objection is that you need hibernate2.jar on the client and .. well .. yes, you do. No easy solution for that one :-)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic