Copy
DTO considerations. (1 min read)
View this email in your browser

On Data Transfer Objects (DTOs)

Data Transfer Objects (DTOs) are data-only types that, as the name suggests, are typically just used to transfer data. However, you don't have to use a DTO to transfer data; you can use any number of other data structures, instead. For instance, if your app exposes an API, you could write it such that it only exposed primitives (string, int, datetime, etc). I don't recommend it, but it's possible, and certainly some areas of your API should use primitives as inputs or return values. Another more common approach is to use your business domain model as your API's model (and thus as your data transfer objects). This requires less code than creating custom objects just for transferring data, but has some downsides because it couples the domain (or data) model to the API's exposed model. There are benefits to separating these concerns, because it lets the two models evolve independently from one another. Another option is to use LINQ's Select method (or something similar) to expose anonymous types as return results from APIs. This is a quick and easy way to avoid exposing your underlying model, but can lead to violation of the DRY principle.

If you're not familiar with having multiple different models in your application, check out this short article on kinds of models.

The costs of adding DTOs to an application that exposes data via some kind of API (whether externally or just for the app's own client application to work with) are the additional code required for the DTOs themselves, as well as the code required to map to and from DTOs and the domain or data model types. Since DTOs are just bags of state, the individual classes tend to require very little time to create - they're just lists of properties. Mapping can be tedious, but tools like Automapper can eliminate a lot of the repetitive aspects of object-to-object mapping, and also can ensure mapping concerns are not mixed into other application logic (i.e. in an MVC controller), which helps you follow SRP.

The benefits are the decoupling already noted, which enables you to evolve your client or API model separately from your domain or data model. You can also easily customize your API model to individual pages, views, or apps, flattening or aggregating data to optimize it for a given client's needs. As your application grows in complexity, both on the client and the server, the cost of not using separate models for these different layers can accrue as a kind of technical debt.

All that said, use your own judgment, and follow Pain Driven Development. If you're not certain you'll need DTOs, they're something that can be added fairly easily later, once you recognize the pain involved in not having them.

 

Keep improving!
Steve (@ardalis)
Recent posts to ardalis.com: PS - I'll be giving a workshop (and some sessions) on DDD with ASP.NET Core at DevIntersection the week of October 24th in Las Vegas. Contact me for a discount on your registration.
Copyright © 2016 Ardalis Services, All rights reserved.


Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list

Email Marketing Powered by Mailchimp