DTO와 Entity 분리에 이어 (https://hellotaja.tistory.com/8)
그렇다면 Entity to DTO, DTO to Entity 방식에 무엇이 있는지 조사하여 의견을 드려보자.
DTO와 Entity 변환 방식 종류
ObjectMapper
이전 프로젝트에서 사용했던 방식.
Model Mapper
출처 : https://lucas-owner.tistory.com/19
https://dbbymoon.tistory.com/4
- 수천 TPS 경우에는 동시성 성능이슈 있음.
- 변환과정에서 리플렉션(구체적인 클래스 타입을 알지 못해도 그 클래스의 메소드, 타입, 변수들에 접근할 수 있도록 해주는 자바 API)이 발생한다는 단점.
MapStruct
출처 : https://velog.io/@musimco/Entity-와-Dto..-쉽게-변환할-수는-없을까
- 다른 Mapping Frameworks들과 비교하여 MapStruct가 같은 시간 높은 처리량과 빠른 속도
수동 변환
출처 : https://www.inflearn.com/questions/15292/comment/41614
- 실행해보지 않고 컴파일시점에서 오류를 잡아낼 수 있음.
- Q.DTO 변환 시 우아한형제들은 어떻게 처리하시나요? 에 대한 당시 19년도 김영한씨 답변을 보면 서비스 특성상 수동으로 변환한다고 한다.
🧐 결론 : MapStruct 라이브러리 사용하는걸로 제안드려보기
DTO 내 코드가 간결해질 수 있고 수동 변환하는게 아니기에 잔실수를 줄임과 동시에 업무 효용을 높일 수 있다.
그러나 모든 엔티티를 DTO로 일괄적인 방식으로 변경하는게 이상적으로 다 안맞아떨어질 수도 있고 그 외에 블로그에 언급된 단점이 발현될 수 있을 것 같다.
이번 프로젝트에서 발현될 문제인지 아직 모르겠다..!
++
DTO와 Entity 간 변환, 어느 Layer에서 하는게 좋을까?
출처 : https://velog.io/@jsb100800/Spring-boot-DTO-Entity-간-변환-어느-Layer에서-하는게-좋을까
https://www.inflearn.com/questions/53023/comment/67137
Controller Layer에서 DTO, Entity 변환 작업
- Service Layer에서 다양한 로직을 처리한 결과를 하나의 DTO에 담아서 보내주는 것이 아니기 때문에, Controller Layer에서 여러 Service 객체를 의존하게 될 가능성이 존재.
- 하지만, Service Layer에서 Entity를 바로 받게 함으로써, Service Layer은 Entity에만 의존하기 때문에 코드 재사용성이 높아진다는 큰 장점.
Service Layer에서 DTO, Entity 변환 작업
- 다양한 경로에서 모일 수 있는 Request DTO들이 전부다 Service Layer로 모이기 때문에 매우 heavy한 Service Layer가 나올 수 있다는 설계적인 리스크 존재. Service Layer도 핵심 비즈니스 로직을 가지고 있는 서비스 로직과, 화면에 맞춘 읽기 전용 서비스 로직을 별도로 분리해서 설계하면 이런 문제를 어느정도 완화할 수 있음
🧐 결론 :이전 프로젝트에서 비슷한 서비스로직이 많았던 경험으로 비추어 볼 때,
개발 전 미리 공통적으로 사용될 수 있는 핵심 비즈니스 로직을 가지고 있는 서비스 로직과 화면에 맞춘 읽기 전용 서비스 로직을 별도로 분리해서 설계한다면 Service Layer에서 DTO, Entity 변환 작업이이뤄지는 게 좋겠음.
또한 상황에 따라 부분적으로는 다른 방식을 채택하는 것도 고려해볼 수 있음.
'IT > Spring' 카테고리의 다른 글
| [Spring] Bean Validation 적용 (@Valid) (0) | 2024.01.23 |
|---|---|
| [Spring] DTO와 Entity 분리 필요성 (0) | 2023.12.18 |
