Spring) 어디서 DTO를 Entity로 변환해야 하는가?

DTO란 무엇일까?

DTO(Data Transfer Object)는 프로세스 혹은 모듈 간에 데이터를 전달하는 객체이다. DAO, VO랑 같이 얘기가 많아 나오는데 사실 그 둘과 큰 관련이 없다고 생각한다.

Entity 자체를 주고 받는 것은 왜 위험한가?

클라이언트와 서버가 데이터를 주고 받을 때, Entity를 사용하는 것은 유지보수적으로나, 보안적으로나 안좋다.(개발자는 편하다) MVC 패턴으로 만들어진 서버와 클라이언트가 통신할 때를 생각해보자. 그리고 DB의 스키마가 변경되어 Entity가 변경된다고 가정하자. 그러면 Entity에 따라 클라이언트에서 주는 Request Body의 형식이 변경되어야 하는가? 만약 그렇다면 너무 대공사이지 않을까? 이번엔 Response 쪽에서 살펴보자. User를 그대로 반환한다 가정해보자. User안에는 노출되서는 안될 비밀번호와 개인 정보들이 담겨있다. Response Dto를 만들지 않는다면 이러한 정보들이 모두 클라이언트에게 노출되는 보안적으로도 매우 취약한 상황에 놓일 수 있다.

DTO는 언제 Entity로 변환되어야 할까?

이 문제는 사실 어디서 변환하든 모두 일리가 있다고 생각한다. View만 뺀다면 말이다.

Repository에서 변환한다.

• Service도 계층이다. Service와 Repository가 통신하기 위한 DTO도 필요하다. 또한 조회된 결과가 Entity와 일치할 것이라는 보장이 없으므로 DTO를 Repository에서 관리하는 것도 현명한 선택이다. (ex. RowMapper)

Service에서 변환한다.

• Service는 모델이라는 계층에 포함된다. 그렇기에 Repository와는 Entity로 통신해도 무방하지만, Controller와 통신하려면 DTO가 필요하지 않을까?

Controller에서 뱐환한다.

• 한 컨트롤러에서 여러 서비스를 사용하게 된다면 각 서비스로부터 받아온 dto들을 다시 모아 새로운 dto를 만들어 클라이언트에게 반환해야하지 않을까?
• DTO는 어찌보면 결국 클라이언트에게 Request를 받고 Response를 보내는 역할인데, 서비스에서 View와 관련된 내용을 고려하는게 맞을까?

여러분이 원하는 곳에서 변환해주면 된다. 다만 변환에 대한 이유를 명확하게 하는 것이 좋다.

DTO를 어디서 Entity로 변환되어야 할까?

만약 객체를 생성하는 역할까지 Service에서 책임을 지게 된다면 Service의 역할이 너무 막중해진다. (Controller 역할도 아니고 Repository 역할도 아니라서 모든 로직들의 짬통이 되가는 기분이다.) 그렇기에 생성하는 역할을 다음과 같이 Dto가 분담하는 것도 좋은 방법이다.

import lombok.RequiredArgsConstructor;

@RequiredArgsConstructor
public class SignUpRequestDto {
    private final String id;
    private final String name;
    private final String password;

    public User toUser() {
        return User.builder().id(id).name(name).password(password).build();

    }
}