728x90
보통은 DTO를 조회해서 Projection을 통해 필요한 데이터를 콕 찝어 가져온다.
문득 든 고민
→ 졸업작품을 준비하면서 '나'는 requestDto와 responseDto를 쪼개서 관리했다.
하지만 Projection을 이용하면 Dto를 한 개로 관리하면서 직접 필요한 데이터만 콕 찝어서 조회 가능하니 select절이 줄어들어 성능을 조금이나마 높일 수 있지 않을까??
결론은
- requestDto와 responseDto를 따로 관리하는 것
- Dto를 하나로 통합시키고 응답값에서는 필요한 데이터만 Projection을 통해 찍어서 가져오기
GPT의 대답
1. Request DTO와 Response DTO 따로 관리하는 방법
장점
클라이언트의 요청과 서버의 응답이 분명하게 나뉘어져 관리되어 가독성이 좋아집니다.
필요한 필드만 요청과 응답에 포함시킬 수 있으므로 불필요한 데이터의 전송을 방지할 수 있습니다.
클라이언트에서 요청 필드와 응답 필드의 변경이 독립적으로 이루어질 수 있습니다.
단점
DTO 클래스가 중복될 수 있어 유지보수가 조금 더 복잡해질 수 있습니다.
DTO 클래스를 추가로 생성해야 하므로 개발 시간이 더 소요될 수 있습니다.
2. Dto를 하나로 통합시키고 응답값에서는 필요한 데이터만 Projection을 통해 찍어서 가져오기
장점
DTO 클래스의 중복을 피할 수 있어 유지보수가 상대적으로 간단해질 수 있습니다.
필요한 데이터만을 조회하고 응답할 수 있어 불필요한 데이터의 전송을 방지할 수 있습니다.
단점
코드 내에서 QueryDSL이나 JPQL로 직접 응답 데이터를 지정해주어야 하므로 코드량이 늘어날 수 있습니다.
클라이언트의 요청과 서버의 응답이 하나의 DTO 클래스에서 관리되어 가독성이 떨어질 수 있습니다.
어떤 방법을 선택할 지 고민 시 고려 사항
프로젝트의 규모와 복잡도
개발자들 간의 팀 워크와 코드 일관성 유지
클라이언트의 요구사항과 API의 특성
결론 : requestDto와 responseDto를 쪼개서 졸업 작품을 만들어 봤으니 Dto를 합쳐서 가져가는 방법으로 다시 만들어봐야겠다!
반응형