-
[Spring] Controller 와 Service 레이어의 DTO,Entity 분리에 관하여Back End/Spring Boot 2021. 12. 25. 11:08
* 이 글은 카프카뮈님의 블로그를 보고 요약한 글입니다.
필자는 Request -> Controller -> Service 로 데이터를 계속 실어보낼 때
한개의 DTO 로 계속 실어보내면서 Service 에서 Entity로 변환하여 작업하였다.
(Request, Response, Service 호출시 매개변수 모두 동일한 DTO 객체였음)
딱히 이유가 있어서라기 보다는 Service에서만 엔티티를 조작하게끔 하여
예기치 못한 상황을 피하고 싶었고, 클라이언트는 나의 엔티티의 정확한 실체를 모르게 하고싶었다.
그러다 카프카뮈님의 블로그 글을 보고 새로운 사실을 알게되어 여기에 정리하고자 한다.
[요약]
1. 의존관계는 최대한 약하게 해야한다! (의존관계 역전원칙)
의존관계가 강할 수록 유지보수비용이 기하급수적으로 늘어날 수 있다.
2. 하나의 DTO로 서비스까지 쭉 전달하는 것은 컨트롤러와 서비스 간 의존을 강화하니까 안된다!
서비스레이어의 모듈화가 어려워진다.
특히 컨트롤러와 서비스의 의존은 매우 위험하다. (by 카프카뮈님의 친구분인 안드로이드 개발자)
[해결방법 1] - 서비스와 컨트롤러의 의존관계 약화
서비스 전용 DTO 를 만든다.
물론 기존 DTO와 중복되는 코드가 많아 비합리적으로 보이지만
서비스와 컨트롤러간의 의존관계를 분리하여 유지보수비용을 줄인다.
[해결방법 2] - 엔티티와 DTO의 의존관계 약화
정적 유틸클래스인 Mapper를 만든다.
엔티티나 DTO 내부에서 toEntity(), toDto() 를 선언하지 않고
Mapper 를 통해 상호변환 함으로써, 엔티티와 DTO의 의존관계를 줄인다.
이로써 엔티티나 DTO가 수정되더라도 Mapper만 수정하면 되는 이점을 가진다.
[Reference]
1. 카프카뮈님의 블로그
728x90'Back End > Spring Boot' 카테고리의 다른 글
[Spring/Network] 서블릿과 WAS에 대하여 (0) 2022.02.25 [Spring] HTTP 405 Error 원인 및 해결 방법 (0) 2022.02.15 [Spring] 심각한 Log4j 보안문제 (feat. Slf4j) (0) 2021.12.24 [Spring] React 로 헤더 내려주기 (브라우저가 접근할 수 있는 헤더 제어하기) (0) 2021.12.03 [Spring] No Creators, like default construct, exist): cannot deserialize from Object value (no delegate- or property-based Creator (0) 2021.12.02