Bird
Raised Fist0
Spring Bootframework~30 mins

Why DTOs matter in Spring Boot - See It in Action

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Why DTOs Matter in Spring Boot
📖 Scenario: You are building a simple Spring Boot application to manage books in a library. You want to send only necessary book information to users, not the entire database entity. This helps keep your app safe and efficient.
🎯 Goal: Build a Spring Boot project that uses a Book entity and a BookDTO (Data Transfer Object) to send limited book data to the client.
📋 What You'll Learn
Create a Book entity class with fields id, title, author, and price
Create a BookDTO class with only title and author fields
Write a method to convert a Book entity to a BookDTO
Use the BookDTO in a controller method to return book data
💡 Why This Matters
🌍 Real World
In real apps, DTOs help control what data is sent over the network, improving security and performance.
💼 Career
Understanding DTOs is essential for backend developers working with APIs and data transfer in Spring Boot applications.
Progress0 / 4 steps
1
Create the Book entity class
Create a class called Book with private fields Long id, String title, String author, and double price. Include public getters and setters for each field.
Spring Boot
Hint

Think of the Book class as a container holding all details about a book. Use private fields and public getters/setters to follow Java best practices.

2
Create the BookDTO class
Create a class called BookDTO with private fields String title and String author. Include public getters and setters for these fields.
Spring Boot
Hint

The BookDTO class holds only the data you want to share. It is like a smaller package with just the title and author.

3
Add a method to convert Book to BookDTO
Inside the BookDTO class, add a public static method called fromBook that takes a Book object as a parameter and returns a new BookDTO with the title and author copied from the Book.
Spring Boot
Hint

This method helps convert a full Book into a smaller BookDTO. Think of it as packing only what you want to send.

4
Use BookDTO in a controller method
Create a Spring Boot controller class called BookController with a method getBookDTO that returns a BookDTO. Inside the method, create a Book object with title "Spring Boot Guide" and author "Jane Doe". Use the BookDTO.fromBook method to convert and return the DTO.
Spring Boot
Hint

The controller sends only the BookDTO to the client. This keeps your app safe by hiding the price and id.

Practice

(1/5)
1. Why do we use DTOs (Data Transfer Objects) in a Spring Boot application?
easy
A. To make the application slower by adding extra layers
B. To increase the size of data sent over the network
C. To replace the database entities completely
D. To carry only the data we want to share and hide internal details

Solution

  1. Step 1: Understand the purpose of DTOs

    DTOs are designed to carry only the necessary data between processes or layers, avoiding exposure of internal details.
  2. Step 2: Analyze the options

    To carry only the data we want to share and hide internal details correctly states the purpose of DTOs. The other options describe incorrect or harmful uses.
  3. Final Answer:

    To carry only the data we want to share and hide internal details -> Option D
  4. Quick Check:

    DTOs protect and simplify data transfer = D [OK]
Hint: DTOs share only needed data, hiding internals [OK]
Common Mistakes:
  • Thinking DTOs replace entities fully
  • Assuming DTOs increase data size
  • Believing DTOs slow down the app
2. Which of the following is the correct way to define a simple DTO class in Spring Boot?
easy
A. public class UserDTO { private String name; private int age; public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } }
B. @Entity public class UserDTO { private String name; private int age; }
C. public interface UserDTO { String getName(); int getAge(); }
D. @Repository public class UserDTO { private String name; private int age; }

Solution

  1. Step 1: Identify correct DTO structure

    A DTO is a simple class with private fields and public getters/setters, without annotations like @Entity or @Repository.
  2. Step 2: Evaluate each option

    public class UserDTO { private String name; private int age; public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } } correctly defines a DTO class with fields and accessors. @Entity public class UserDTO { private String name; private int age; } wrongly uses @Entity, which is for database entities. public interface UserDTO { String getName(); int getAge(); } defines an interface, not a DTO class. @Repository public class UserDTO { private String name; private int age; } wrongly uses @Repository, which is for data access layers.
  3. Final Answer:

    public class UserDTO { private String name; private int age; public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } } -> Option A
  4. Quick Check:

    DTO = simple class with getters/setters = B [OK]
Hint: DTOs are plain classes with getters/setters, no @Entity [OK]
Common Mistakes:
  • Adding @Entity annotation to DTO
  • Using interfaces instead of classes for DTO
  • Marking DTO as @Repository
3. Given this Spring Boot controller method, what will be the output JSON when calling /user?
@GetMapping("/user")
public UserDTO getUser() {
    UserDTO dto = new UserDTO();
    dto.setName("Alice");
    dto.setAge(30);
    return dto;
}
medium
A. {"name":"Alice"}
B. {"UserDTO":{"name":"Alice","age":30}}
C. {"name":"Alice","age":30}
D. Error: Cannot serialize UserDTO

Solution

  1. Step 1: Understand default JSON serialization in Spring Boot

    Spring Boot uses Jackson to convert returned objects to JSON, serializing all public getters by default.
  2. Step 2: Analyze the returned UserDTO object

    UserDTO has name and age fields with getters, so JSON will include both as simple key-value pairs.
  3. Final Answer:

    {"name":"Alice","age":30} -> Option C
  4. Quick Check:

    DTO fields serialize as JSON keys = A [OK]
Hint: Returned DTO converts to JSON with all getters [OK]
Common Mistakes:
  • Expecting nested JSON with class name
  • Assuming partial fields serialize
  • Thinking serialization causes error
4. What is wrong with this DTO class that causes a runtime error when Spring Boot tries to deserialize it?
public class ProductDTO {
    private String name;
    private int price;
    public ProductDTO(String name, int price) {
        this.name = name;
        this.price = price;
    }
}
medium
A. Fields should be public, not private
B. Missing default no-argument constructor
C. Constructor parameters should be annotated with @Autowired
D. Class should be annotated with @Entity

Solution

  1. Step 1: Identify deserialization requirements

    Jackson requires a default no-argument constructor to create an instance before setting fields via setters or reflection.
  2. Step 2: Check the DTO class

    This class only has a parameterized constructor and no default constructor, causing Jackson to fail during deserialization.
  3. Final Answer:

    Missing default no-argument constructor -> Option B
  4. Quick Check:

    Jackson needs no-arg constructor = A [OK]
Hint: DTOs need no-arg constructor for JSON serialization [OK]
Common Mistakes:
  • Thinking fields must be public
  • Adding @Autowired to constructor parameters
  • Confusing DTO with entity needing @Entity
5. You have an entity class User with many fields, but you want to expose only id and email in your API response. How should you use a DTO to achieve this cleanly?
hard
A. Create a UserDTO with only id and email fields, map User to UserDTO before returning
B. Return the User entity directly and ignore unwanted fields in the frontend
C. Add @JsonIgnore to all unwanted fields in the User entity
D. Use the User entity but rename unwanted fields to empty strings

Solution

  1. Step 1: Understand data exposure risks

    Returning the full User entity exposes all fields, risking sensitive data leaks.
  2. Step 2: Use DTO to control data

    Creating a UserDTO with only id and email fields and mapping User to UserDTO ensures only desired data is sent.
  3. Step 3: Evaluate other options

    Return the User entity directly and ignore unwanted fields in the frontend risks exposing all data. Add @JsonIgnore to all unwanted fields in the User entity mixes entity with serialization concerns and can be error-prone. Use the User entity but rename unwanted fields to empty strings is a bad practice and confusing.
  4. Final Answer:

    Create a UserDTO with only id and email fields, map User to UserDTO before returning -> Option A
  5. Quick Check:

    DTOs control exposed data = C [OK]
Hint: Use DTO to expose only needed fields safely [OK]
Common Mistakes:
  • Returning full entity directly
  • Using @JsonIgnore on entity fields
  • Modifying entity fields to hide data