We have a legacy web service architecture. I have now the luxury to use EJBs (EJB 3) for new development and I would like to avoid DTOs as it creates 3 parallel layers. If I send the hibernate objects directly to client, what would become of the relations? Creating a detached object wont solve the issue as the associated objects might already be fetched somewhere else. Serializing such hibernate object will force whole graph to be serailized. What approach (other than DTOs) do you use for complex objects?
Asked
Active
Viewed 1,566 times
0
-
1see http://stackoverflow.com/questions/182323/how-to-serialize-hibernate-collections-properly for some ideas – gcooney Feb 16 '11 at 14:52
2 Answers
3
For remote access (remote EJBs, Web Services etc.) I actually prefer DTOs. They don't include any (surrogate) primary key, only business keys, and provide the client view, while the entities are private to the service and can be changed as needed.
Puce
- 37,247
- 13
- 80
- 152
-
how do you deal with (parent child) relationships? DTO containing another DTO? What if you have several such child relationships? What if the view does not require all of the child relationships? – anergy Feb 16 '11 at 17:49
-
Yes, of course, the DTOs can form an object graph as needed and serve as a filtered view on the entities (omitting the fields which are not needed by the clients). – Puce Feb 16 '11 at 18:04
1
You can use a DDD aggregate pattern: http://dddcommunity.org/node/88, from my experience it has the benefit of a domain model + DTO, as the whole is treated as a unit.
And by I have now the luxury to use EJBs I hope you mean EJB3... because the previous verions were very painful to use
