I am writing a web service. I am also writing a web client which uses this web service. I've experienced some of the pain of trying to send domain objects over the wire (cyclic references, lazy loading, etc. -- see e.g. Davy Brion's post on why it's a bad idea). So, I am going to use DTOs to transfer between these two tiers.
Being in charge of both ends, I am able to control the design of the DTOs. Now I'm wondering, what drives the design of the DTO? Is it the user interface on the client-side? Do I create DTOs based on what views/screens the client will have? Or it something service-side that should dictate the contract of the DTOs I send out, and the client has to work with what it's given?
Designing your DTOs can be a hard task especially because there are many concerns coming into play. Usually performance considerations can prevent you from completely abstracting from the UI. Let's say you have multiple UI representations for the same object, e.g. a tree, grid and a detail pane. Each of them will need a different subset of properties, based on what you actually display. You can design a common DTO to contain a union of all those properties, but it might be expensive to construct such a DTO, load the data from the store and transfer it over the wire. You might end up transferring a rich object graph with lots of data just to display the name of the object in the UI.
On the other hand, if you go for a DTO per UI context, you'll quickly end up with a class explosion problem having hundreds of DTO representing nearly the same object, with a slightly modified subset of properties. Reuse of code and readability will suffer and it might become unmanageable in the long run.
As there is no silver bullet, it requires a sensitive approach where you find the compromise between the performance and other aspects, maybe using up to 3 different DTO types per Domain object and reusing them in different contexts.