Section 6: Data Transfer Objects
Introduction:
In our previous sections, we have seen how to create a Model, create a table for this model in the DB, and retrieve the data from this table using the IRepository and Unit of Work patterns.
In this section, we shall see what Data Transfer Object is.
Why DTOs?
The primary purpose of DTO is to hide the actual model from the client. As you have seen in the previous sections, the Hotel Model will map it as-is to the table in the Database. If you show the Hotel Model as-is to the client (such as a browser), you will be showing unnecessary data to the client.
For instance, our Hotel Model looks as below:
public class Hotel
{
[Key]
public int Id { get; set; }
[Required]
public string Name { get; set; }
[Required]
public string Province { get; set; }
public DateTime Created { get; set; }
public DateTime Established { get; set; }
}
This model is exposed to the client. In other words, suppose there is a browser (client) calling our API to get the list of top oldest Hotels, they would get the list of hotels with all properties of Hotel (Id, Name, Province, Created, Image, and Established) as in the model. We are providing unnecessary data to the client, and also they may expose a few vulnerabilities. Obviously, it will increase the response payload size too.
Hence, we can create a new class, and its primary task is to transfer the data from the Data Access layer to the client. It may have less(often its less) or more properties than that of the model. This class is called Data Transfer Objects (DTOs).
Let us create a DTO for our Hotel Model:
Create a folder called DTOs in the project and add the below class.
public class HotelDTO
{
public int Id { get; set; }
public string Name { get; set; }
public string Province { get; set; }
}
Using the DTO, we are hiding the
Created and
Established properties of the Hotel. Although this is not the best example, I hope you got the purpose of DTOs.
A better example is to use the User Model; a user model will have the following properties: Username, Password, Role, ID, Security Questions. If you always return the Username for all CRUD operations, you expose the "over-posting" vulnerability. Hence, for the "Create" operation, we shall not use any DTO. However, for the "Read" operation, we shall create a ReadUserDTO, which will have only Username and Role. For the Update and Delete, we shall create another DTO, say, UpdelUserDTO, which will have only Username property. I hope you understood the logic of DTOs.
Outro:
In this section, we have seen the benefits of DTOs. However, you would have wondered who this is used; when we pass the data to the client, we have to convert it from Hotel model to HotelDTO class. We can do it manually, but doing it every time and everywhere in the code is cumbersome. To convert from one object to another, we have a library called
Auto Mapper. In the next
section, we shall see how to use Auto Mapper and its advantages.
