DTO vs entity separation benefit in Spring Boot - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why separate DTOs from entities in Spring Boot?

In a Spring Boot application, why is it beneficial to separate Data Transfer Objects (DTOs) from entity classes?

A Because entities cannot be serialized to JSON

B To reduce the number of classes in the project

C To protect the database schema from direct exposure and allow flexible API evolution

D Because DTOs automatically handle database transactions

💡 Hint

Think about how exposing entities directly might affect your API and database design.

Separating DTOs from entities helps protect the internal database structure from external clients. It also allows the API to evolve independently without changing the database schema.

❓ component_behavior

intermediate

What happens if you expose entities directly in API responses?

Consider a Spring Boot REST API that returns entity objects directly as JSON responses. What is a likely consequence of this approach?

A Entities will be converted to DTOs automatically by Spring Boot

B The API will automatically validate all input data

C The application will run faster due to fewer classes

D Clients may receive sensitive or unnecessary data fields tied to the database schema

💡 Hint

Think about what data entities contain and how that might affect clients.

Entities often contain fields that should not be exposed externally, such as internal IDs or audit information. Returning entities directly can leak this data.

❓ state_output

advanced

What is the output when mapping entity to DTO with missing fields?

Given an entity with fields id, name, and password, and a DTO with only id and name, what will be the output JSON when mapping the entity to the DTO and returning it in a Spring Boot REST controller?

Spring Boot

public record UserEntity(Long id, String name, String password) {}

public record UserDTO(Long id, String name) {}

// Mapping method
public UserDTO toDTO(UserEntity entity) {
  return new UserDTO(entity.id(), entity.name());
}

// Controller method returns toDTO(userEntity)

A {"id":1,"name":"Alice"}

B {"id":1,"name":"Alice","password":"secret"}

C {"name":"Alice"}

D {"id":1,"password":"secret"}

💡 Hint

Only fields declared in the DTO will be serialized in the JSON response.

The DTO only contains id and name, so the JSON output excludes password. This protects sensitive data from being exposed.

📝 Syntax

advanced

Identify the correct DTO mapping syntax in Spring Boot

Which of the following code snippets correctly maps a UserEntity to a UserDTO in Spring Boot using a constructor?

Spring Boot

public record UserEntity(Long id, String name, String password) {}
public record UserDTO(Long id, String name) {}

A UserDTO dto = new UserDTO(userEntity.id, userEntity.name);

B UserDTO dto = new UserDTO(userEntity.id(), userEntity.name());

C UserDTO dto = new UserDTO(userEntity.getId(), userEntity.getName());

D UserDTO dto = new UserDTO(userEntity.getId, userEntity.getName);

💡 Hint

Records use accessor methods without 'get' prefix.

Java records provide accessor methods named after the fields, so userEntity.id() and userEntity.name() are correct.

🔧 Debug

expert

Why does exposing entities cause a security risk in Spring Boot?

A developer returns JPA entity objects directly from a REST controller. Later, they notice sensitive fields like passwords are exposed in API responses. Why does this happen?

A Entities include all fields by default, so sensitive data is serialized unless explicitly excluded

B DTOs are required to serialize entities properly

C Spring Boot automatically encrypts entity fields, so passwords are safe

D Entities cannot be serialized to JSON, so this is impossible

💡 Hint

Think about what happens when an object is converted to JSON without filtering.

Entities contain all fields, including sensitive ones. Without DTOs or annotations to exclude fields, all data is serialized and sent to clients, causing security risks.