이전 게시판 제작 과정에선 Controller에 엔티티를 직접 연결해서 요청 값으로 Board 엔티티를 직접 받게 했다. 하지만 이와 같이 엔티티 값을 직접 받게 되면 문제가 발생한다. 이번에는 DTO에 대해서 그리고 프로젝트에 DTO를 연결한 과정을 기록하려고 한다.
우선, DTO란 무엇일까?
DTO(Data Transfer Object, 데이터 전송 객체)란 프로세스 간에 데이터를 전달하는 객체를 의미한다. 데이터를 전송하기 위해 사용하는 객체이기에 그 안에 비즈니스 로직 같은 복잡한 코드는 존재하지 않고 순수하게 전달하고 싶은 데이터만 담겨있다. Entity와 Controller를 섬이라고 한다면 DTO는 그 사이를 연결해 주는 다리와 같은 역할을 하는 것이다.
그러면 왜 Entity와 Controller 사이에 DTO라는 다리를 놓아야 하는 것일까?
만약 Controller에서 Entity를 직접 받으면 다음과 같은 문제점이 있다.
- Entity에 프레젠테이션 계층을 위한 로직이 들어간다.
- 프레젠테이션 계층이란?
HTTP 요청을 받고 이 요청을 비즈니스 계층으로 전송하는 역할을 하는 계층. Controller가 프레젠테이션 계층에 속한다.
- 프레젠테이션 계층이란?
- Entity에 API 검증을 위한 로직이 들어간다.(@NotEmpty 등)
- 실무에서는 특정 Entity를 위한 API가 다양하게 만들어지는데, 한 Entity에 각각의 API를 위한 모든 요구사항을 담기는 어렵다.
- Entity가 변경되면 API 스펙이 변한다.
그러면 DTO를 추가하면 어떻게 될까?
- Entity와 프레젠테이션 계층을 위한 로직을 분리할 수 있다.
- Entity와 API스펙을 명확히 분리할 수 있다.
- Entity가 변경되어도 API스펙이 변하지 않는다.
따라서 별도의 DTO를 파라미터로 받게 해야하는 것이다.
그럼 이제 게시판 프로젝트에 DTO를 추가해 보자.
우선 Controller에서 Entity를 직접 받는 부분은 게시글 작성 부분과 게시글 수정 부분이 있다. 따라서 작성부분의 DTO는 BoardPostDto라고 이름짓고 수정부분의 DTO는 BoardChangeDto라고 이름 지었다.
@Data : 이 어노테이션은 Lombok에서 제공하는 것으로 @Getter / @Setter, @ToString, @RequiredArgsConstructor, @Value 등을 자동으로 적용시켜준다. 하지만 이 어노테이션을 쓰면 Setter를 남발하게 되고 @RequiredArgsConstructor로 인한 문제가 생기기 때문에 쓰는 것을 지양하는 편이 좋다.(@RequiredArgsConstructor로 인한 문제가 왜 생기는지는 다음에 알아보자)
그런데 @RequierdArgsConstructor를 또 넣어놨네? 다 만들고 봤는데 나중에 수정해야지
이렇게 필요한 것들만 들어간 DTO를 만들어 주고 Controller에서 DTO를 파라미터로 받도록 넣어주면
DTO추가가 끝난다.
솔직히 처음에는 DTO라는 개념도 잘 잡히지도 않았고 어떻게 작성해서 추가해야하나를 굉장히 많이 고민했었다. 그런데 막상 만들어보니 생각보다 간단해서(개념은 어려웠지만) 좀 허탈했었던거 같다. 그래도 이번 공부로 여러가지를 알게 됐으니 만족한다. 김영한님의 강의에서는 @Data 어노테이션을 되도록이면 쓰지 말라고 하셨었으니 다음 프로젝트 제작에서는 @Data가 아닌 필요한 어노테이션만 넣어서 제작해 봐야겠다.
'Spring MVC' 카테고리의 다른 글
@PathVariable과 @RequestParam의 차이에 대한 공부 (0) | 2025.02.20 |
---|---|
Spring MVC)게시판 만들기 - 웹어플리케이션 실행 및 부족한 점 고찰 (0) | 2025.02.07 |
Spring MVC)게시판 만들기 - Controller 생성 (1) | 2025.02.07 |
Spring MVC)게시판 만들기 - Service 생성 (0) | 2025.02.06 |
Spring MVC)게시판 만들기 - Repository 생성 (0) | 2025.02.05 |