[스진초5기/Spring] DTO, Entity 변환은 어느 계층에서 일어나야할까?

2023.11.08 - [Framework/Spring] - [스진초5기/Spring] DTO, VO, Entity

[스진초5기/Spring] DTO, VO, Entity

이전 포스팅에서 DTO, Entity, VO과 각각 어떤 역할을 수행하고 어떤 차이를 있는지 정리했다. 각 역할에 따라 DTO와 Entity는 특정 순간에 변환돼서 사용되어야 한다. 이런 변환작업은 어느 계층에서 처리해 주는 게 가장 좋은 방법일까? 

DTO, Entity 변환은 어느 계층에서 일어나야할까?

기존 프로젝트할 때는 DTO와 Entity 변환 작업을 Service계층에서 일괄적으로 처리했었다. DTO가 일반적으로 계층 간의 데이터 전달을 위해 사용되기 때문에 Controller에서 Serivice로 요청값을 보낼 때 DTO로 전달되고 결과값이 Service에서 Controller로 응답 보낼 때도 DTO로 전달하여 사용했다.

해당 주제에 대해 자료를 조사하다 보니 생각보다 많은 프로젝트에서 Controller에서 변환과정을 진행하는 것을 알게 되었다. 

Controller 계층에서의 변환

Controller에서의 변환은 서비스입장에서는 가장 이상적인 방법 중 하나일 것이다. 우리가 3 계층을 분리하여 사용하는 것은 각각의 역할에 따라 책임을 분리하는 데에 있다. 서비스입장에서의 가장 이상적인 상황은 순수한 비즈니스 로직만을 처리를 담당하는 것이다. 

// Controller Code
@PostMapping("/foods")
public FoodDto registFood(@RequestBody FoodDto foodDto){
    // DTO -> Entity 변환
    Food request = toEntity(foodDto);
    Food response = foodService.save(request);

    // Entity -> DTO 변환
    return toResponse(response);
}

// Service Code
@Override
public Food save(Food food) {
    return foodRepository.save(food);
}

위 코드는 Controller 계층에서 DTO, Entity 변환작업을 처리한 로직이다. 이와 같이 변환작업이 이루어지면 Controller 계층의 일부 코드가 포함되기 때문에 복잡해질 수 있지만, 상대적으로 Service 계층은 핵심 비즈니스 로직만 처리를 하면 된다. 그러면 서비스 계층은 엔티티에만 의존하기 때문에 재사용성이 높아진다.

Service 계층에서의 변환

현실적으로 Controller에서의 변환만 사용하기 어려운 이유가 존재한다. 위 코드처럼 단순한 코드라인이면 상관없겠지만 프로젝트를 구현하다 보면 비즈니스 로직의 처리가 Entity의 담긴 값만으로 처리하기 어려운 경우가 발생하게 된다. 핵심 비즈니스 로직을 처리 위해 많은 부가정보가 필요할 수 있기 때문이다. 

그렇다고 Service 계층을 Entity에만 의존하여 순수하게 구현하기 위해 외부에서 일부 비즈니스로직을 구현할 수는 없다. 계층을 나눈 이유가 사라지기 때문이다. 

이러한 문제 때문에 일부 코드는 Service 계층에 DTO, Entity 변환작업을 진행한다. 

public FoodDto save(FoodDto foodDto) {

    // DTO, Entity 변환 작업을 Service 로직 내부에서 실행한다.
    Food food = toEntity(foodDto);
    Food save = foodRepository.save(food);
    FoodDto response = toResponse(save);

    return response;
}

위와 같은 문제는 해결할 수 있겠지만 DTO들이 Service 계층에서 처리되기 때문에 덩치가 커진 Service 로직이 구현될 수 있는 위험이 발생할 수는 있다. 또한 특정 DTO에 의존하기 때문에 코드 재사용성이 떨어지게 된다. 

정리 

DTO, Entity 변환에 대해 간단하게 정리해 보았다. 각 계층마다 장점과 단점을 가지고 있기 때문에 상황에 맞게 쓰는 게 중요할 것 같다. 

프로젝트의 규모, 구조에 따라 일관적인 방법이 존재하며, 특정 상황에 따라 적절하게 맞춰가는 게 필요하다. 

아직 프로젝트 경험이 맞지 않아 사실 상황에 맞는 방식을 고르는 데는 많이 애먹을 거 같다. 그렇기 때문에 프로젝트를 진행하면서 두 방법을 다 써보면서 감을 잡아 후에 내가 온전히 이해가 된다면 포스팅의 내용을 보강 진행하면 좋은 경험이 될 것 같다.

Reference 

https://www.inflearn.com/questions/53023/dto%EC%9D%98-layer%EC%97%90%EB%8C%80%ED%95%B4-%EC%A7%88%EB%AC%B8-%EB%93%9C%EB%A6%BD%EB%8B%88%EB%8B%A4

https://velog.io/@jsb100800/Spring-boot-DTO-Entity-%EA%B0%84-%EB%B3%80%ED%99%98-%EC%96%B4%EB%8A%90-Layer%EC%97%90%EC%84%9C-%ED%95%98%EB%8A%94%EA%B2%8C-%EC%A2%8B%EC%9D%84%EA%B9%8C

https://jiwondev.tistory.com/251

# ToEntity , ToDTO는 다른 포스팅으로 정리