Data Transfer Object Tips (Part 1)

One classification of objects in many applications is the Data Transfer Object, or DTO. Here are some tips that may help you avoid problems when using these objects.

Sponsor - DevIQ

Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos.

Show Notes / Transcript

Data Transfer Objects, or DTOs, are, as the name suggests, objects whose main purpose is to transfer data. In Object Oriented Programming, we typically think about objects as encapsulating together state, or data, and behavior. DTOs have the distinction of being all about the data side of things, without the behavior.

Why do we need DTOs?

DTOs are used as messages. They transfer information from one part of an application to another. Depending on where and how they transfer information, they might have different names. Often, they're simply referred to as DTOs. In some cases, you may see them characterized as View Models, API Models, or Binding Models. Not all view models in MVC apps are DTOs, but many can and probably should be. For instance, in an ASP.NET MVC application, you typically don't want to have any behavior in the ViewModel type that you pass from a controller action to a view. It's just data that you want to pass to the view in a strongly typed fashion. If you're following the MVVM pattern to build apps using WPF or something similar, then your ViewModel in that scenario is supposed to have behavior, not be a DTO. Ideally we'll come up with a better name for ViewModels in MVC apps, but obvious choices like ViewData are already overloaded.

Why shouldn't DTOs have behavior?

DTOs don't have behavior because if they did, they wouldn't be DTOs. Their entire purpose is to transfer data, not to have behavior. And because they are purely data objects, they can easily be serialized and deserialized into JSON, XML, etc. Your DTO's data schema can be published and external systems can send data to your system in a wire format that your system can translate into an instance of your DTO. If your DTO has behavior on it, for instance to ensure its properties are only set to valid values, this behavior won't exist in the string representation of the object. Furthermore, depending on how you coded it, you might not be able to deserialize objects coming from external sources. They might not follow contraints you've set, or you might not have provided a default public constructor, for instance.

The goal of DTOs is simply to hold some state, so you can set it in one place and access it in another. To that end, the properties on a DTO should all have public get and set methods. There's no need to try to implement encapsulation or data hiding in a DTO.

That's it for this week. Next week I'll talk some more about DTOs and provide a list of Do's and Don'ts.