originally published at medium

Let’s say you go to a coffee shop. Your coffee costs $5. Do you hand the barista your entire wallet, let them dig through your credit cards, embarrassing old photos, and loose change, and just trust them to only take the $5?

Of course not. You pull out exactly what they need — the five-dollar bill — and hand it over.

If you are building APIs in .NET and returning your database entities directly to the user, you are basically handing the frontend your entire wallet. You’re exposing things you shouldn’t, sending more data than necessary, and tying your database structure directly to your user interface.

The solution? Data Transfer Objects (DTOs). Let’s break down exactly what they are, why you absolutely need them, and how to write them in modern .NET without overcomplicating things.

What Exactly is a DTO?

DTO stands for Data Transfer Object.
At its core, a DTO is just a dumb, lightweight box used to carry data from one place to another — usually from your backend server to the client (like a web browser or mobile app), or vice versa.

What makes it “dumb”?

• No business logic:
  A DTO doesn’t calculate taxes, check if a username is already taken in the database, or know what your company’s refund policy is.

• No database connections:
  A DTO doesn’t know what Entity Framework is. It doesn’t save or delete things.

• Strictly for data (and basic bouncer duties):
  It is primarily a collection of getters and setters. However, for data coming into your API, DTOs often act as the “bouncer” at the door. They handle basic input validation (e.g., checking if an email is formatted correctly or a password is long enough) to reject bad data before it ever reaches your core application.

The 3 Big Reasons You Need DTOs

If creating a separate class(or preferably records) just to hold data sounds like tedious extra work, I hear you. But skipping this step causes massive headaches down the road. Here is why DTOs are non-negotiable in production apps.

• Security (Hiding Your Secrets) Imagine you have a User entity in your database. It probably looks something like this:

public class User 
{
    public int Id { get; set; }
    public string Username { get; set; }
    public string Email { get; set; }
    public string PasswordHash { get; set; }
    public string ResetToken { get; set; }
}

If your API returns this User object directly when someone logs in, you just sent their encrypted password and a sensitive reset token straight to their web browser. A malicious user can easily open Chrome DevTools and see exactly what you sent.

A UserResponseDto fixes this by only including what the client actually needs to see:

public record UserResponseDto(int Id, string Username, string Email);

• Preventing “Over-fetching” (Performance) Let’s say you are building an online store. You need a simple dropdown menu of all your products so the user can filter a search.

If you return the Product database entity, you aren't just sending the product's name. You're sending the 500-word description, the weight, the supplier ID, and maybe a list of 20 high-res image URLs.

Sending all that unused data across the internet wastes bandwidth, slows down your app, and runs up your cloud hosting bill. A ProductDropdownDto that only contains the Id and Name solves this instantly.

• Decoupling (Breaking the Tight Grip) Your database schema and your API response are two completely different things. If you don’t use DTOs, they are bolted together. If your database administrator decides to rename the FirstName column to GivenName, your API suddenly starts spitting out GivenName. If a mobile app is relying on the old FirstName property, you just broke the mobile app. DTOs act as a buffer. You can rename your database columns all day long, and as long as you map the new column to the old property in your DTO, the frontend doesn’t notice a thing.

How to Write DTOs in Modern .NET

In modern C#, the way you write a DTO usually depends on which direction the data is going: coming in (Requests) or going out (Responses).

• Data Going Out (Response DTOs) When you are sending data out of your API, C# records are the perfect tool for the job. They are concise and immutable by default (meaning once the data is set, it can’t be accidentally changed mid-flight). In older versions of C#, creating DTOs (classes) was annoying because you had to write a bunch of boilerplate code.

The Old Way (Classes):

public class ProductDto
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

The Modern .NET Way (Records):
public record ProductDto(int Id, string Name, decimal Price);
That one line does exactly the same thing. It’s clean, it’s beautiful, and it takes two seconds to write.

• Data Coming In (Request DTOs) When data is coming into your API (like a user registering for an account), this is where your DTO acts as the bouncer using Input Validation. You can use Data Annotations right on the DTO to reject bad requests instantly.

public record RegisterUserDto(
    [property:Required, MaxLength(20)] string Username,
    [property: Required, EmailAddress] string Email,
    [property: Required, MinLength(8)] string Password
);

If a user tries to send an empty email, the API automatically returns a 400 Bad Request before your database even knows what happened.

Getting Data into the Box (Mapping)
So, you have your database Entity and you have your shiny new DTO. How do you get the data from one to the other? This is called "mapping."

Method 1: Manual Mapping (The Safest Route)
You can just write the code to copy properties over yourself. This is great for performance and readability. If you are querying a database with Entity Framework Core, you can do this directly in your query using Select:

var products = await _context.Products
    .Select(p => new ProductDto(p.Id, p.Name, p.Price))
    .ToListAsync();

Method 2: Auto-Mappers (The Lazy Route)
If you have massive objects with 50 properties, typing them out manually gets old fast. Developers often use third-party libraries to map things automatically based on matching property names.

• AutoMapper:
  The granddaddy of them all. Very popular, but can get messy to configure in large apps.

• Mapster:
  A much faster, more modern alternative to AutoMapper. Highly recommended if you want to go the automated route.

The Bottom Line
Yes, creating DTOs means adding more files to your project. Yes, it means you have to write a little bit of code to map data from your database models to your DTOs.

But the payoff is massive. Your app becomes significantly more secure, your API payloads become lightning fast, and your frontend developers will thank you for giving them clean, predictable data structures instead of messy database tables.