Search code examples
asp.netdesign-patternsoopdto

How to effectively use DTO objects (Data Transfer Objects)?


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.


Solution

  • 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.