작성
·
78
0
위 강의에서는 Response 부분을 service 레이어에 response 패키지 안에 관리를 하고 있습니다.
개인적인 생각으로는 요청을 받는 부분은 최상단 Presentation Layer 이고 궁극적으로 어떠한 결과를 return 해주는 것 또한 Presentation Layer 이라고 생각합니다.
그렇기에 requestDto 는 controller 쪽에 있는게 맞고 responseDto 또한 controller 쪽에 있어야 하는게 맞지 않을까 하는 생각이 듭니다!
혹시 위 부분 어떻게 생각하시는지 궁금합니다.
답변 3
0
0
안녕하세요, 압구정 자발개 님!
네, 맞습니다. 강의 예제는 간단한 프로젝트이기 때문에 Service에서 반환하는 Response를 그대로 사용했는데, 이대로도 사실 의존 관계 상 큰 문제는 없습니다.
만약 실제 최종 응답에 사용되는 형태와 Service에서 반환하는 데이터의 형태가 달라야 한다면, 각 레이어에 DTO를 별개로 두고 변환 과정을 거쳐야 할 거예요. (강의 중에 Request가 계층을 넘어오면서 변환 과정을 갖도록 했던 것 처럼요.)
도움이 되셨기를 바랍니다.
감사합니다. 🙂
0
안녕하세요, 인프런 AI 인턴입니다. 압구정 자발개님, 질문 주셔서 감사합니다.
DTO(Data Transfer Object)의 위치에 대한 논의는 소프트웨어 아키텍처에서 빈번한 주제 중 하나입니다. DTO를 어떻게 배치하느냐에 따라 계층 간 의존성과 응집도가 서로 영향을 미칠 수 있기 때문인데요. 간단한 설명과 함께 기존에 관련된 토론에서 유사한 질문 사례를 추천 드리겠습니다.
Presentation Layer와 의존성: Presentation Layer는 사용자 인터페이스와 직접 연결되어 있으며, 이곳에서 Request와 Response를 처리합니다. 그럼에도 불구하고 Response DTO를 Service Layer에 두는 경우는 종종 있습니다. 이는 비즈니스 로직에서 직접 생성한 데이터를 저장하거나 조작할 DTO를 관리하기 위해서인데요, 비즈니스 로직의 결과물을 한 곳에서 통합 관리함으로써 응답의 일관성을 유지하고, 코드의 재사용성도 높일 수 있습니다.
Controller의 책임 고려: 요청과 응답을 다루는 것이 Controller의 주된 역할이라고 할 수 있지만, 이런 구조만 생각할 경우 Controller가 비대해질 위험이 있습니다. 이 경우 단일 책임 원칙(Single Responsibility Principle)을 위반할 수 있게 되죠. 따라서 각 레이어의 역할을 명확히 하고, Service Layer에서 응답 객체를 만들어 Controller가 이를 사용하는 구조는 유지보수성이나 코드 재사용성에서 유리한 점이 많습니다.
기존에 유사한 논의가 포함된 controller, service용 dto를 분리시키는 것에 대한 질문에서 두 계층 간의 의존성을 어떻게 설정하고 관리할지에 대해 좋은 인사이트를 얻으실 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.