DTOs: best practices

Admin 1
Viewed 34637

I am considering to use DTOs instead of passing around my domain objects. I have read several posts here as well as elsewhere, and i understand there are several approaches to getting this done.

If i only have about 10 domain classes in all, and considering that i want to use DTOs rather than domain objects for consumption in my Views (WPF front ends), what is the recommended approach. I think using tools like automapper etc maybe an overkill for my situation. So i am thinking of writing my custom mapper class that will have methods for converting a domain type to a DTO type.

What is the best way to do this, are there any sample to get me started to do this?

Second question: When writing those methods that will create DTOs, how do i deal with setting up all the data, especially when the domain type has references to other domain objects? Do i write equivalent properties in the DTO for mapping to those refernece types in the domain class? Please ask if i have not put my second question in proper words. But i think you understand what i am trying to ask.

Thrid question: When writing DTOs, should i write multiple DTOs, each containing partial data for a given domain model, so that each of it can be used to cater to a specific View's requirement, or should the DTO have all the data that are there in the corresponding model class.

dto
7 Answers

Question 1: If the DTO's you need to transfer are just a simple subset of your domain object, you can use a modelmapper to avoid filling your codebase with logic-less mapping. But if you need to apply some logic/conversion to your mapping then do it yourself.

Question 2: You can and probably should create a DTO for each domain object you have on your main DTO. A DTO can have multiple DTO's inside of it, one for each domain object you need to map. And to map those you could do it yourself or even use some modelmapper.

Question 3: Don't expose all your domain if your view does not require it to. Also you don't need to create a DTO for each view, try to create DTO's that expose what need to be exposed and may be reused to avoid having multiples DTO's that share a lot of information. But it mainly depend's on your application needs.

If you need clarification, just ask.

user_31119940

We all know what Dtos are (probably). But the important thing is to overuse DTOs or not.

Transfering data using Dtos between "local" services is a good practice but have a huge overhead on your developer team.

There is some facts:

  1. Clients should not see or interact with Entities (Daos). So you always need Dtos for transferig data to/from remote (out of the process).
  2. Using Dtos to pass data between services is optional. If you don't plan to split up your project to microservices there is no need to do that. It will be just an overhead for you.

And this is my comment: If you plan to distribute your project to microservices in long future. or don't plan to do that, then DON'T OVERUSE DTOs

You need to read this article https://martinfowler.com/bliki/LocalDTO.html

user_3104010
Related