📖 Introduction
When developing applications in ASP.NET Core, you often need to move data between different parts of the application – for example, from the database to the API, or from the server to the client. Directly exposing your database models can create problems such as security risks, unnecessary data exposure, or tight coupling. This is where DTOs (Data Transfer Objects) are very useful. They act as simple classes designed just for carrying data safely and efficiently.
We will understand in simple and natural words what DTOs are, why they are needed, and how to use them effectively in ASP.NET Core applications.
🤔 What is a DTO?
A DTO (Data Transfer Object) is basically a container of data. It’s a class that usually has only properties without any logic. Its purpose is to transfer data between different layers of an application.
DTOs are not database models.
They only include the data that you actually want to send or receive.
They help make applications more secure and organized.
Example of a DTO
public class UserDto
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
}
This DTO focuses only on Id, Name, and Email, even if the actual database User entity has more fields like password or internal tokens.
🔒 Data Security
One of the biggest reasons for using DTOs is security. When you expose your database models directly, you might accidentally share sensitive data such as passwords, tokens, or internal IDs with clients.
DTOs give you the control to decide exactly which fields should be exposed.
Example
// Database Entity
public class User
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
public string PasswordHash { get; set; } // sensitive data
}
// DTO
public class UserDto
{
public int Id { get; set; }
public string Name { get; set; }
public string Email { get; set; }
}
👉 Here, the PasswordHash never reaches the client, ensuring safety.
🎨 Data Shaping
Clients often don’t need the entire entity; they only need certain fields. With DTOs, you can create a custom data shape for specific requirements.
For example, if your Product entity has 15 properties, but the client only needs the Name and Price, you can create a ProductDto:
public class ProductDto
{
public string Name { get; set; }
public decimal Price { get; set; }
}
👉 This ensures that unnecessary fields (like supplier details or stock count) are not sent, making responses lighter and cleaner.
⚡ Performance Improvement
DTOs also improve application performance. By sending only the required fields, the response size becomes smaller, meaning:
Faster network transfer
Less data processing
Better performance on mobile and low-bandwidth networks
In large applications, this small optimization can make a huge difference for end-users.
🔗 Decoupling Layers
When you directly use database models in your API responses, any small change in your database structure can break your API. This creates a tight connection between database design and API design.
With DTOs, you keep things independent. You can change database models without affecting the API contract.
Example
Database model changes
Email→EmailAddressDTO still uses
Email, so API remains consistent for clients

Join the conversation! Your thoughts help the community grow.