프로그래밍/spring

DTO와 Entity의 변환 Layer는 어디가 좋을까?

승민아 2024. 2. 29. 15:52

여러 Controller를 작성하다가

내가 어떨땐 다음과 같이 Controller에서 DTO -> Entity 변환을 하여 Service단에 넘겨주는 코드를 작성하기도 하고,

PosterController.java

Poster poster = PosterRequest.toEntity(posterRequest);
posterService.addPoster(poster, files, locationId, member);

 

 

내가 어떨땐 Controller에서 DTO를 그대로 넘기고 Serive단에서 DTO -> Entity 변환을 하는 코드를 작성하기도 한게 눈에 들어왔다.

PosterService.java

void addPoster(PosterRequest posterRequest) {
    Poster poster = PosterRequest.toEntity(posterRequest);
}

 

Entity와 DTO의 변환 필요성에 대해서는 한번 정리해본적이 있다.

 

Entity -> DTO 필요성

https://non-stop.tistory.com/664

 

Entity와 DTO의 분리 필요성 및 방법

Entity 자체를 요청과 응답을 처리하는데 그대로 사용하니 다음과 같은 문제 또는 비효율적인 부분이 발생했다... 먼저 회원 엔티티를 보자. @Entity @Data public class Member { @Id @GeneratedValue(strategy = Gener

non-stop.tistory.com

 

Controller나 Service를 구분하지 않고 한곳에 다 코드를 넣으면 될까?

Controller와 Service의 구분 역할은 다음과 같다.

Controller

  1. 클라이언트 요청을 받아 처리하는 역할
  2. 사용자의 입력 유효성 검사

Service

  1. 비즈니스 로직을 포함하여 처리하는 역할
  2. 여러 Controller에서 공유되는 비즈니스 로직을 넣어 코드 중복을 낮추고 재사용, 유지보수를 높임

=> 컨트롤러에는 폼 데이터, 화면에 뿌릴 데이터를 모아주는 그런 웹 계층을 위한 코드만 존재하는것이 좋고. 콘솔로만 동작해야하는 경우가 있을 수 있으니 그런건 서비스가 담당하는것이 좋다.

 

Entity와 DTO의 변환은 어디서 이뤄지는것이 좋을까?

Service단에서 이뤄지면?

Service단에 DTO를 넘겨 작업이 이뤄진다면. 다양한 경로, 방법으로 들어오는 DTO를 처리하기위해 Service단이 Heavy해질 수 있다.

즉, 특정 DTO에 의존하여 여러 컨트롤러에서 재사용성이 떨어진다는 것이다.

그러나 컨틀롤러가 Entity는 모르고 DTO만 알고 있기에 값의 변경에 안전? 할 수 있다.

 

Controller단에서 이뤄지면?

Service에서 Entity만을 받기 때문에 Service의 재사용성이 크게 증가한다.

그러나 웹 계층 처리를 위한 코드가 존재해야하는 Controller 구조가 위배될 수 있다.

 

 

참고 QnA : 

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

 

dto의 layer에대해 질문 드립니다. - 인프런

dto는 Controller Layer에서 dto->Entity로 치환하여 Service레이어로 넘기는편이 맞을까요? Service Layer에서 dto->Entity로 치환하는것이 맞을까요?제 개인적인 생각으로는 다양한 경로에서 모일 수 있는 request

www.inflearn.com

 

이상적으로 서비스 계층에서 엔티티를 받는것이 좋다고한다.

그.러.나. 다양한 상황이 있기에 한 프로젝트안에서도 맞는 상황을 적용하는게 맞다고한다...