컨트롤러에서 받는 request dto에 대해 궁금한점
445
작성한 질문수 32
강사님께서 짜주신 코드에서는
컨트롤러에서는 요청을 받는 DTO를 Domain까지 전파해서
활용하시던데, 보통 코드를 보면 컨트롤러에서 받은
Request Dto -> Domain으로 변환 후에 비즈니스 로직을 처리하는 코드도 많이 봤어서 어떻게 옳고 그른지 궁금합니다.
또한 Request Dto를 도메인에서 파라미터로 받아서 활용해도 되는지도 궁금하구요.
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
두잇베스트님, 요청받은 DTO의 사용에 대해 질문해주셨군요!
일반적인 경우, 컨트롤러에서 받은 Request DTO는 도메인 객체로 변환한 후, 비즈니스 로직을 처리합니다. 이는 계층 간의 역할을 명확히 구분하여, 각 계층이 자신의 책임에 맞는 작업을 수행하도록 하기 위함입니다. DTO는 주로 계층 간 데이터 교환을 위한 객체로, 비즈니스 로직이 포함된 도메인 모델과 역할이 다릅니다.
반면에, Spring MVC의
DomainClassConverter를 사용할 경우 컨트롤러에서 도메인 객체를 직접 받고, 이를 모델에 추가하여 사용할 수 있게 되므로, DTO를 굳이 도메인 객체로 변환하지 않아도 됩니다. 주로 간단한 CRUD 작업에서 유용하게 사용할 수 있으며,findById(...)같은 메소드를 사용하여 필요한 변환을 자동으로 수행해 줍니다. 하지만 복잡한 비즈니스 로직이 도메인에 포함될 경우, 필요한 데이터만을 담은 Request DTO를 통해 도메인 객체를 생성하거나 업데이트하는 것이 좋습니다.
DTO를 도메인에서 파라미터로 직접 받아 사용하는 것은 유효성 검증이나, 단순한 데이터 전달 등의 경우에 적합할 수 있으나, 도메인의 핵심 로직에서는 구분해서 사용하는 것이 좋습니다. 이는 코드의 가독성, 유지보수성 및 도메인 모델의 응집도를 높이는 데 기여합니다.
아래 문서에서 DomainClassConverter와 관련된 더 많은 정보를 확인하실 수 있습니다:
- Spring Data JDBC - Reference Documentation
- Spring Data JPA - Reference Documentation
도움이 되셨길 바랍니다!
UserService, CertificationService 책임 분리 기준 질문
0
28
1
service.port 패키지로 이동한 UserRepository가 infrastructure에 있는 UserEntity에 의존
0
59
1
Service 소형 테스트 질문
0
83
1
조회 시 엔티티를 조회하는 것이 아닌QueryDSL을 많이 사용 시 Dto는 어떻게 하나요?
0
116
1
controller 의 port 패키지의 service 인터페이스 사용
0
72
1
빌드 문제
0
92
1
빌드 안 되시는 분들 참고
0
102
1
update에서 Repository.save
0
105
1
최종 완성된 코드를 받아 볼 수 있을까요?
0
156
1
의존성 역전으로 해결한 외부의존성?
0
162
1
좋은 설계
0
180
1
Controller에 테스트
0
139
1
JPA가 아닌 Mapper 아키텍처 기반 테스트 코드 작성
0
242
0
영속성 객체 구분으로 인한 JPA와 Querydsl의 Projection 사용
0
224
1
인프라계층 구현체와 테스트 구현체에 대한 질문
0
223
1
실습 코드 커밋
0
373
1
UserEntity 메서드
0
294
2
CertificationServiceTest에서 MailSender 인터페이스가 아닌 FakeMailSender를 이용하는 것
0
217
1
레이어드 아키텍처 개발에 대하여
0
231
1
BDDMockito의 when을 사용한 코드가 given 절에 있는 이유가 궁금합니다.
0
223
1
테스트에서 주입과 생성
0
198
1
프로젝트 코드는 제공해주시지 않는건가요?
0
382
2
개선된 아키텍처의 구조
0
277
1
서비스 레이어의 단위 테스트 범위 고민
0
188
1