DTO와 Entity의 변환 Layer는 어디가 좋을까?
여러 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
- 클라이언트 요청을 받아 처리하는 역할
- 사용자의 입력 유효성 검사
Service
- 비즈니스 로직을 포함하여 처리하는 역할
- 여러 Controller에서 공유되는 비즈니스 로직을 넣어 코드 중복을 낮추고 재사용, 유지보수를 높임
=> 컨트롤러에는 폼 데이터, 화면에 뿌릴 데이터를 모아주는 그런 웹 계층을 위한 코드만 존재하는것이 좋고. 콘솔로만 동작해야하는 경우가 있을 수 있으니 그런건 서비스가 담당하는것이 좋다.
Entity와 DTO의 변환은 어디서 이뤄지는것이 좋을까?
Service단에서 이뤄지면?
Service단에 DTO를 넘겨 작업이 이뤄진다면. 다양한 경로, 방법으로 들어오는 DTO를 처리하기위해 Service단이 Heavy해질 수 있다.
즉, 특정 DTO에 의존하여 여러 컨트롤러에서 재사용성이 떨어진다는 것이다.
그러나 컨틀롤러가 Entity는 모르고 DTO만 알고 있기에 값의 변경에 안전? 할 수 있다.
Controller단에서 이뤄지면?
Service에서 Entity만을 받기 때문에 Service의 재사용성이 크게 증가한다.
그러나 웹 계층 처리를 위한 코드가 존재해야하는 Controller 구조가 위배될 수 있다.
참고 QnA :
dto의 layer에대해 질문 드립니다. - 인프런
dto는 Controller Layer에서 dto->Entity로 치환하여 Service레이어로 넘기는편이 맞을까요? Service Layer에서 dto->Entity로 치환하는것이 맞을까요?제 개인적인 생각으로는 다양한 경로에서 모일 수 있는 request
www.inflearn.com
이상적으로 서비스 계층에서 엔티티를 받는것이 좋다고한다.
그.러.나. 다양한 상황이 있기에 한 프로젝트안에서도 맞는 상황을 적용하는게 맞다고한다...