작성
·
223
·
수정됨
0
안녕하세요! 덕분에 테스트 코드 잘 짜고있습니다 😋
강사님은 QueryDsl 에서 QueryProjection 을 통해 dto 로 한번에 조회하게 되었을때 해당 dto 를 service 계층에 두시는지, 혹은 repository 계층에 dto 를 하나 더 두시는지 궁금합니다!! 둘다 아니라면 어떻게 하시는지도 궁금합니다! (레이어드 아키텍처를 사용한다고 가정)
만약 Service 단에서 querydsl 을 위한 dto 를 생성하게 되면, repository 계층에서 service 계층을 알게되어 의존성측면에서 좋지 않다고 생각합니다.
그렇다고 repository 계층에서 querydsl 을 위한 dto 를 생성하게되면 의존성측면에서는 괜찮다고 볼 수 있지만 좀 번거롭다고 생각이듭니다. (계층마다 dto 가 하나씩..?)
선생님께서는 어떤 방식으로 해결하시는지가 궁금합니다! 제가 잘못생각한거라면 조언좀 부탁드립니다!
(말을 너무 못하네요.. 죄송합니다)
답변 2
0
PrivilegaEscalate 님, 안녕하세요!
저는 Repository에 DTO를 두고 의존성 측면에서 관리를 하는 편입니다.
그렇다고 해서 강의 중에 Controller -> Service로 DTO 간 변환을 했던 것처럼 번거롭게 DTO를 각각 두어 계층을 구분하지는 않고요 ㅎㅎ (말씀하신대로 비용적인 측면입니다.)
Service 레이어에서 Repository의 DTO를 바로 사용하도록 하고 있어요.
도움이 되셨기를 바랍니다.
감사합니다 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
PrivilegeEscalate님, 질문해주셔서 감사합니다.
QueryDsl에서 QueryProjection을 사용할 때 해당 DTO의 위치는 실제 프로젝트의 구조 및 팀 내 컨벤션에 따라 결정될 수 있습니다. 하지만 일반적인 레이어드 아키텍처를 고려할 때, DTO는 주로 서비스 레이어와 레포지토리 레이어 사이에서 데이터 전송 객체로서의 역할을 합니다. 따라서, QueryProjection을 사용하여 DTO를 생성하는 경우 이 DTO는 데이터 접근 계층(repository)과 서비스 계층(service)의 중간에서 데이터 전달의 역할을 하게 됩니다.
레포지토리 계층에 위치시키는 방법이 의존성 관리 측면에서는 더 적절할 수 있습니다. 이 경우, 레포지토리 계층은 데이터를 조회하고 DTO로 변환하는 책임을 갖게 되며, 서비스 계층은 이 DTO를 사용하여 비즈니스 로직을 처리하게 됩니다. 즉, DTO는 레포지토리 계층에서 정의되고 사용되어, 서비스 계층으로 데이터를 전달하는 데 사용됩니다.
이와 관련하여 제공된 자료 중에 Querydsl에 대한 특별한 언급은 없으나, 일반적인 원칙으로 볼 때, 서비스 계층에서 레포지토리 계층을 알지만, 레포지토리 계층이 서비스 계층을 알지 못하게 하는 것이 중요합니다. 따라서, DTO는 레포지토리 계층에 위치하는 것이 관례적으로 권장됩니다. 각 계층별로 DTO를 별도로 두는 것이 번거로워 보일 수 있지만, 계층 간의 의존성을 명확히 분리하고, 각 계층의 책임을 명확하게 하는데 도움이 됩니다.
만약 의존성 관리와 계층 간의 분리에 더 주안점을 두기 원한다면, 레포지토리 계층에서의 DTO 정의를 선호할 수도 있습니다. 물론, 이는 프로젝트의 요구사항, 팀 내 정해진 아키텍처 가이드라인, 개발 관행에 따라 달라질 수 있습니다.
PrivilegeEscalate님의 프로젝트에 가장 적합한 구조를 선택하시길 바랍니다. 추가로 궁금하신 부분이 있으시면 언제든지 질문해주시기 바랍니다.