DTO를 Request, Response로 나누는 이유
2025. 2. 15. 04:34ㆍWEB/SPRING
반응형
DTO(Data Transfer Object)를 request와 response로 나누는 이유는 입력과 출력의 역할이 다르기 때문.
📌 주제: "도서 관리 시스템" (Library Management System)
- 사용자가 책을 추가할 때 Request DTO
- 사용자가 책 정보를 조회할 때 Response DTO
✅ 1. Request DTO (입력)
- 클라이언트 → 서버로 데이터를 보낼 때 사용
- 주로 POST, PUT, PATCH 요청에서 사용됨
- 유효성 검사(ex: @Valid, @NotNull)를 적용할 수 있음
- 데이터베이스 엔티티와 1:1 매핑되지 않아도 됨 (클라이언트가 필요한 데이터 구조를 따름)
package com.example.library.dto.request;
import lombok.Getter;
import lombok.NoArgsConstructor;
import javax.validation.constraints.NotBlank;
import javax.validation.constraints.Positive;
@Getter
@NoArgsConstructor
public class BookRequestDto {
@NotBlank
private String title;
@NotBlank
private String author;
@Positive
private int price;
public BookRequestDto(String title, String author, int price) {
this.title = title;
this.author = author;
this.price = price;
}
}
✨ 사용 예시
@PostMapping("/books")
public ResponseEntity<Void> createBook(@RequestBody @Valid BookRequestDto requestDto) {
bookService.createBook(requestDto);
return ResponseEntity.ok().build();
}
👉 사용자가 보낸 데이터를 받아서 책을 등록하는 로직
- @NotBlank → title, author가 비어 있으면 안 됨
- @Positive → price는 0보다 커야 함
✅ 2. Response DTO (출력)
- 서버 → 클라이언트로 데이터를 보낼 때 사용
- 주로 GET 요청에서 사용됨
- 엔티티 그대로 노출하지 않도록 보호하는 역할
- 불필요한 정보(예: createdAt, updatedAt, DB ID)를 제거 가능
- 클라이언트가 필요로 하는 형식으로 가공 가능
package com.example.library.dto.response;
import com.example.library.entity.Book;
import lombok.Getter;
@Getter
public class BookResponseDto {
private Long id;
private String title;
private String author;
private int price;
public BookResponseDto(Book book) {
this.id = book.getId();
this.title = book.getTitle();
this.author = book.getAuthor();
this.price = book.getPrice();
}
}
✨ 사용 예시
@GetMapping("/books/{id}")
public ResponseEntity<BookResponseDto> getBookById(@PathVariable Long id) {
BookResponseDto responseDto = bookService.getBookById(id);
return ResponseEntity.ok(responseDto);
}
👉 책 정보를 클라이언트가 보기 좋게 가공해서 응답
- id를 포함하여 책의 정보를 조회할 수 있음
🔥 DTO를 나누는 이유
구분 Request DTO Response DTO
역할 | 사용자가 입력하는 데이터 | 사용자에게 보여줄 데이터 |
사용 예시 | POST /books | GET /books/{id} |
유효성 검사 | @Valid 사용 가능 | 필요 없음 |
변환 목적 | toEntity() 메서드로 엔티티 변환 | 엔티티를 원하는 형태로 가공 |
보안 | DB ID 노출 필요 없음 | 불필요한 필드 숨김 가능 |
✅ 정리
- Request DTO: 사용자가 입력하는 데이터를 검증하고 엔티티로 변환
- Response DTO: 엔티티 데이터를 클라이언트가 보기 좋은 형태로 가공
반응형
'WEB > SPRING' 카테고리의 다른 글
이메일 인증을 처리하는 방식: @GetMapping 대신 @PostMapping 사용 이유 (0) | 2025.02.19 |
---|---|
@PutMapping, @PatchMapping, @GetMapping, @PostMapping 에 관하여... (0) | 2025.02.15 |
Spring 자동 재시작 (0) | 2024.07.25 |
Spring #5 MVC와 템플릿 엔진 (0) | 2024.07.16 |
Spring #4 정적 컨텐츠 (0) | 2024.07.16 |