How to effectively use DTO objects (Data Transfer

Question

What is the best way to implement DTOs?

My understanding is that they are one way to transfer data between objects. For example, in an ASP.Net app, you might use a DTO to send data from the code-behind to the business logic layer component.

What about other options, like just sending the data as method parameters? (Would this be easiest in asces wher there is less data to send?)

What about a static class that just holds data, that can be referenced by other objects (a kind of global asembly data storage class)? (Does this break encapsulation too much?)

What about a single generic DTO used for every transfer? It may be a bit more trouble to use, but reduces the number of classes needed to work with (reduces object clutter).

Thanks for sharing your thoughts.

Answer 1

DTOs are used to send data over the wire, not between objects. Check out this post: POCO vs DTO

Answer 2

I keep it simple and map one DTO class to one db table. They are lightweight so I can send them everywhere, including over the wire.

Answer 3

I've used DTO's to:

• Pass data between the UI and service tier's of a standard 3-tier app.
• Pass data as method parameters to encapsulate a large number (5+) of parameters.

The 'one DTO to rule them all' approach could get messy, best bet is to go with specific DTO's for each feature/feature group, taking care to name them so they're easy to match between the features they're used in.

I've never seen static DTO's in the way you mention and would hesitate at creating DTO singletons like you describe.

Answer 4

I think it's pretty common to use DataSet/DataTable as the "one DTO to rule them all". It's easy to load them from the database, and persist the values back, and they can be easily serialized.

I would definitely say they are more trouble to use. They do provide all of the plumbing, but programming against them is a pain (lots of casting, null checks, magic strings, etc). It would be interesting to see a good set of extension methods to make working with them a little more "natural".

Answer 5

Thanks for all the helpful ideas...

A summary + my take on this:

--If there is a small amount of data to move and not too many places to move it, regular parameters may suffice

--If there is a lot of data and/or many objects to move it to, a specially created object may be easiest (DTO object).

--A global data object that can be referenced (rather than passed) by various objects would seem to be frowned on...however, I wonder if there isn't sometimes a place for it within a particular sub-system? It is one way to reduce the amount of data passing. It does push the limits of "good encapsulation", however in specific instances within specific layers, perhaps it could add simplicity to a particluar assemply of classes. Thus one would lose class-level encapsulation, but could still have assembly-level encapsulation.

Answer 6

I wish it could be as simple. Though DTO originated due to network distribution tiers of a system there can be whole load of issues if domain objects are returned to View layers. Here are some of them:

1.By exposing Domain objects to View layer, Views become aware of structure of domain objects, which lets view makes some assumptions about how related objects are available. For example if a domain object "Person" was retunrned to a view to which it is "bound" and on some other view, "Address" of Person is to be bound, there would be a tendency for Application layer to use a semantic like person.getAddresse() which woukd fail since at that point Address domain object might have not been loaded at point. In essence, with domain objects becoming available to View layers, views can always make assumptions about how data is made available.

2.) when domain objects are bound to views (more so in Thick clients), there will alwyas be a tendency for View centric logic to creep inside these objects making them logically corrupt.

Basically from my experience I have seen that making domain objects available to Views create architectural issues but there are issues with use of DTO's also since use of DTO creates additional work in terms of creation of Assemblers (DTO to Domain objects and reverse), Proliferation of analogous objects like Patient domain object, Patient DTO and perhaps Patient bean bound to view.

Clearly there are no right answers for this specially in a thick client system.

I borrowed this short and not complete but true answer to DTO cliché from:
http://www.theserverside.com/discussions/thread.tss?thread_id=32389#160505