tags:

views:

117

answers:

1

May a DTO have relations to other DTOs?

Any more opinions on this topic :-) ?

+1  A: 

The point of a DTO is to allow simple transfer of data between two processes, to reduce method calls.

Therefore, you'd expect to see a small number of DTOs, sometimes even one DTO, in any interface. Normally, they'd be very coarse-grained.

I'd be suspicious that DTOs with lots of relationships weren't DTOs at all. And that they were too closely matching your domain objects.

Can you post some examples?

Joe R
I have no concrete example. I just wonder if navigation properties "are allowed".
Rookian
What are navigation properties?
Joe R
A navigation property is for example a list of addresses on a person. i.e. person.Addresses.Street (Addresses is the navigation property). I can "navigate" from a person to its addresses.
Rookian
As long as the the Addresses are DTOs too, rather than domain objects, I don't see a problem.
Joe R
But this mentioned DTOs are not flat or may I be wrong?
Rookian
What do you mean by DTOs are not flat?
Joe R
The DTO looks like a tree, because of the Customer.Addresses and so on. Or am I wrong?
Rookian
I don't see problem with that. As long as the DTO is exactly that, just a transfer object. By using an Address DTO inside the Customer DTO, the intention is to save typing out the same Street, Suburb, State, Zip Code information that can be used in a number of DTO's. I do the exact same thing myself :) To clarify, DTO's usually just have getters and setters, no methods.
rob_g
That shouldn't be a problem, but I wouldn't introduce class hierarchies as well otherwise you're moving away from DTOs.
Joe R
providing a list of Customer.Addresses means for me using methods for CRUD operations. Especially in many to many associations providing a public list is not that good, because you have to synchronize both ends! Furthermore the information hiding principle goes here imo. So I am still confused about using "DTO trees".
Rookian