Strictly speaking, the DTO (Data Transfer Object) pattern was originally created for serializing and transmitting objects. But since then, DTOs have proven useful for things like commands, parameter objects, events, and as intermediary objects when mapping between different contexts (e.g. importing rows from an Excel worksheet).
One consequence of this widespread use is that, now days, naming a class SomeSortOfDto doesn’t tell me much about what the object is for — only that the object carries data, and has no behaviour.
Here’s a few suggestions for better names that might help indicate its purpose:
- SomeSortOfQueryResult
- SomeSortOfQueryParameter
- SomeSortOfCommand
- SomeSortOfConfigItem
- SomeSortOfSpecification
- SomeSortOfRow
- SomeSortOfItem (for a collection)
- SomeSortOfEvent
- SomeSortOfElement
- SomeSortOfMessage
By no means this is a definitive list — it’s just a few examples I can remember using off the top of my head right now. But you get the general idea — try not to call your objects as just DTOs, but give them names that describe their purpose too.
April 17, 2010
4 Comments
Bevan Arps on April 17, 2010 at 10:43 pm.
You make a good point that overusing the “DTO” extension effectively robs it of value.
Inspired a follow-up post on my own blog:
http://www.nichesoftware.co.nz/blog/201004/naming-and-convention
Pingback: DotNetShoutout
Gautam on April 21, 2010 at 9:13 pm.
Good point, seems like this is getting overused.
Dimitris on April 22, 2010 at 8:47 am.
Excellent list; and while we’re at it, lets make clear that mapping Models to DTOs is *not* in the purpose list. Models should be serializable and usable from end to end.