DTO vs Entity in Spring Boot: Why You Shouldn’t Expose Your Entities

If you’ve been working with Spring Boot for a while, you’ve probably seen two kinds of classes popping up in tutorials or codebases: Entities and DTOs (Data Transfer Objects).

At first, it might be tempting to just use your Entity everywhere. After all, it already has the fields you need, it maps directly yo the database, and it saves you time. But that shortcut often turns into a headache later.

In this article we’ll break down what Entities and DTOs are, why mixing them up can cause trouble, and how to use them correctly in your projects.

What is an Entity?

An Entity is a class that presents a table in your database. In Spring Boot with JPA, it’s usually annotated with @Entity .

Example:

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;
    private String email;
    private String password;

    // getters and setters
}

This User class maps directly to a user table in your database.

It’s perfect for persistence, but it’s not meant to travel outside your data layer.

What is a DTO?

A Data Transfer Object (DTO) is a simple object used to transfer data between layers (usually between your backend and the frontend).

DTOs are not tied to your database. Instead, they’re shaped to deliver exactly the data your client needs.

Example:

public class UserDTO {
    private String username;
    private String email;

    // constructors, getters, setters
}

Notice something?

The DTO does not include the password. That’s because we don’t want to leak sensitive data to the outside world.

Why Not Expose Entities Directly?

Here is why exposing your Entity in APIs is risky:

1. Security risks: Imagine accidentally sending the password field in a JSON response. Not a good thing.
2. Leaky abstractions: Entities are tied to your database schema. If your DB changes, your API might break unnecessarily.
3. Performance issues: Entities often carry more data than you actually need to return. This leads to bloated responses.
4. Flexibility: DTOs let you shape your API responses differently from your database. For example, you could merge fields, rename them or flatten relationships.

Converting Between Entities and DTOs

There are a few ways to turn an Entity into a DTO and back:

1. Manual Mapping

public UserDTO convertToDTO(User user) {
    UserDTO dto = new UserDTO();
    dto.setUsername(user.getUsername());
    dto.setEmail(user.getEmail());
    return dto;
}

2. Using ModelMapper (less boilerplate)

ModelMapper modelMapper = new ModelMapper();
UserDTO dto = modelMapper.map(user, UserDTO.class);

3. MapStruct (compile-time safe and fast)

@Mapper
public interface UserMapper {
    UserDTO toDTO(User user);
    User toEntity(UserDTO userDTO);
}

Example in a REST Controller

Instead of returning an Entity directly:

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userRepository.findById(id).orElseThrow();
}

You should return a DTO:

@GetMapping("/users/{id}")
public UserDTO getUser(@PathVariable Long id) {
    User user = userRepository.findById(id).orElseThrow();
    return userMapper.toDTO(user);
}

Now only safe and useful data is exposed to the client.

DTOs vs Entities

Use Entities for persistence (saving and retrieving data from the database), DTOs for communication (what your API sends and receives). Think of Entities as your “internal raw data” and DTOs as the “public-facing shape” of that data.

👉 Next time you’re building a Spring Boot API, pause before returning your Entity directly. Instead, ask yourself: Do I really want the outside world to see my database schema?