인프런 커뮤니티 질문&답변
작성한 질문수
DTO를 서비스 레이어에서 사용할 수 밖에 없다면
작성
·
11
답변 2
0
엔티티가 아니면서 데이터를 담는 모든 오브젝트가 DTO는 아닙니다. DTO는 오브젝트가 계층이나 시스템의 경계를 넘어서 데이터를 전달하는 것에 주 목적인 경우에 DTO라고 할 수 있습니다. 만약 JDBC 등을 이용해서 쿼리 결과를 매핑해서 담는 오브젝트는 활용 용도에 따라서 여러가지로 부를 수 있습니다.
만약 도메인 모델 패턴을 적용하고 싶다면 JDBC를 사용하더라도 도메인 모델로 설계된 오브젝트에 매핑할 수 있습니다. 이 경우 JDBC를 이용해서 도메인 오브젝트를 만들어 그 안에 로직을 담아 활용할 수 있습니다. 물론 이때도 서비스 계층에서 리턴할 때 이 오브젝트를 사용하겠죠. 이런 경우엔 DTO라기 보다는 도메인 오브젝트를 리턴한다고 해도 됩니다.
물론 목적이 단순 조회인 경우에, 그리고 도메인 모델과 직접 연결되지 않는 경우엔 일종의 DTO에 담아서 리턴할 수 있습니다. 이 경우 DTO가 애플리케이션 로직을 담고 있고 애플리케이션 로직에 의존하고 있기 때문에 서비스 계층에 DTO를 두는 것이 자연스럽습니다.
0
안녕하세요, 인프런 AI 인턴입니다. klord님.
서비스 레이어에서 DTO를 사용하는 시나리오에 대한 질문을 주셨군요. JDBC Template이나 Native Query를 사용할 때 엔티티를 사용하기 어렵다고 판단하신 것 같습니다. DTO를 사용하는 것이 불가피한 경우라면, 어느 정도 트레이드 오프를 수용할 필요가 있습니다.
엔티티 사용의 어려움과 DTO 사용
직접 조회의 필요: JDBC Template이나 Native Query를 사용하여 데이터를 직접 조회할 경우, 엔티티 관리와는 별개의 로직이 필요하고, 이로 인해 DTO를 사용하는 것이 합리적인 선택일 수 있습니다.
서비스 레이어에서의 활용: 이때 DTO를 사용해 데이터를 주고받는 것은 데이터베이스를 직접 조작하는 코드의 복잡성을 캡슐화하여 유지보수를 용이하게 하는 장점이 있습니다.
레이어 간의 역할 유지: DTO를 서비스 레이어에서 사용하는 것은 계층 간 책임과 역할을 확실히 분리할 수 있도록 돕습니다. 이는 데이터의 흐름을 명확히 하고, 이후 변경이나 확장 시 비교적 안전하게 설계를 유지할 수 있습니다.
유사한 질문과 답변
비슷한 고민을 다룬 답변 중 하나로, 엔티티와 DTO 사용에 대한 고려사항의 내용을 참고하시길 권장드립니다. 여기서는 엔티티와 DTO가 어떤 상황에서, 왜 필요한지를 설명하고 있으며, 이를 통해 설계를 어떻게 개선할 수 있을지에 대한 인사이트를 얻으실 수 있습니다.
위에서 언급된 방법을 실제 프로젝트에 적용할 때 발생할 수 있는 다양한 시나리오를 고려하시면 도움이 될 것 같습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
토비님이 말씀하신대로 생각은 하고 있었는데 뭔가 본능적으로는 사소한 부분에서 통일성을 해치게 되는 게 아닐까 하는 불편함이 있었던 것 같습니다.
답변 감사합니다.