dto 구조 설계 질문드립니다...

Question

마이바티스에서 특정 필드만 조회할때 딱 그 필드에만 맞는 dto를 만들다보면 dto가 너무 많아지는것같아엔터티처럼 모든 칼럼을 가지는 dto를 만들어 서비스와 레파지토리 사이에서만 사용 하는 Dto를 만들고서비스에서 컨트롤러와 서비스 사이에서만 사용하는 내부dto로 컨트롤러로 데이터를 전달하고컨트롤러에서는 응답dto에 담아 내보내는 식으로 구조를 잡았습니다질문 :취업 포트폴리오인데 이런 구조가 괜찮을까요..?괜찮다면 레파지토리의 메소드에서 요구하는 인자가 1개여도 일관성을 위해 엔터티 처럼 사용하는 dto에 담아 보내는게 좋을까요..?번외로 요청을 할때 하나의 파라미터라도 최대한 dto를 활용하는게 좋을까요..?혼자 공부 하다 보니 어떻게든 기능은 구현하겠는데 어떤 구조가 좋을지 감이 잘 잡히지 않아서 질문드립니다

snabinop · Answer

정리해보면 DTO를 총 3가지 계층에 따라 나누신 것 같습니다.Repository: 각 테이블 접근 시 해당 테이블의 모든 컬럼을 가진 하나의 DTOService: 비즈니스 로직에 필요한 내부용 DTOController: 요청/응답 DTORepository에서 하나의 DTO로 통합했지만 서비스 계층에서 다시 내부용 DTO로 나누게 된다면,특정 테이블 필드 조회 시마다 DTO를 생성하는 것과 같이 DTO의 수가 증가함으로 효율적인 방법은 아닌 것 같습니다.따라서 DB 조회를 위해 각 테이블당 모든 컬럼을 가진 하나의 DTO를 생성하고 서비스 계층에서는 해당 DTO를 활용하며,이후 컨트롤러에서는 요청/응답에 필요한 데이터를 담기 위해 각각의 DTO를 생성하는 방식이 좋을 거 같습니다.또는 각 API 역할에 따라 DB 접근 DTO를 생성하되, 이를 서비스 계층에서도 사용하고 위와 같이 컨트롤러에서는요청/응답 DTO를 따로 만드는 것도 좋은 방법일 것 같습니다.추가로 DTO를 사용하신다는 것은 Request Body에 데이터를 담아 API 요청을 하는 것 같은데Body에 담을 필요가 없는 데이터일 경우 쿼리 스트링 형태로 하나의 파라미터를 전달해도 무방합니다.즉, 해당 API의 목적에 따라 Request DTO 사용 여부를 결정하시면 될 것 같습니다.

adadawd · Answer

테이블과 매핑되는 DTO를 만드시는건 충분히 좋은 시도입니다. 다만, 테이블별로 모두 만들어 주셔야 합니다.컨트롤러와 서비스 사이의 내부 DTO를 만드실 필요 없이 응답DTO에 담아 보내시면 됩니다.이러한 구조일때 요청DTO -> 서비스 -> 테이블매핑DTO 변환 -> 레포지토리, 쿼리 실행 결과를 서비스가 테이블매핑DTO로 받으면 응답DTO로 반환하여 컨트롤러에게 던져주시면 됩니다.즉 컨트롤러-서비스에서는 요청/응답 DTO가 움직이고 서비스에서는 요청 DTO를 테이블과 매핑된 DTO로 변환하여 레포지토리에 전달, 결과로 받은 DTO를 응답 DTO로 변환하여 컨트롤러에게 반환 해주는 식으로 됩니다.이렇게 사용해보며 빌더도 써보시고, 정적 팩터리 메서드도 써보시고 하면 좋을것같아요.

independent · Answer

이상적이고 좋은 설계는 기능마다 DTO를 1:1로 매핑하는 거라 생각합니다. 유지보수에 정말 좋거든요.Member라는 도메인에 있는 모든 값들을 DTO로 만들고, Member와 관련된 응답들을 해당 DTO를 사용해서 Req/Res한다면 나중에 유지보수할 때 정말 힘듭니다.3번 대답이 질문의 답이 될 거 같아요. 하나의 파라미터가 외부에 노출되면 안 되는 경우 (쿼리스트링이나 URL)에는 Request Body로 DTO에 담아 받으면 됩니다.아래는 제가 이메일 인증에 사용하는 DTO입니다.public record SendEmailAuthRequest( String email ) { }

apidevelop222 · Answer

dto는 두개로 나뉘어집니다 요청 dto, 응답 dto 요청 dto는 사실 변화가 많이 없기에 만드는걸 추천합니다. 응답 dto는 회사 내부정책에 따라 많이 다릅니다.첫번째로는 마이바티스에서 컬럼을 * 로 전부 가져와서응답 dto는 테이블 도메인에 있는 모든 값들로 만듭니다. 사실 dto가 아니라 Entity 혹은 VO라고 하는게 더 적절합니다. 이후에 dto 객체로 매핑하시면 됩니다.전부가져온다음, 상황에 맞게 코드단에서 처리하면 되기에 빠른 개발을 가능하게 합니다.두번째로는 마이바티스에서 처음부터, select id, name ... 처럼 select 할때 부터 필요한 컬럼만 가져옵니다.필요한 컬럼만 가져오므로 성능은 첫번째보단 좋습니다. 응답 dto를 만들지 않아도 되어서 좋습니다.상황에 맞게 하시면됩니다.

ㅇㅈㅇ · Answer

요즘 개발트랜드와 반대로 가는 겁니다.요즘은 한 테이블 DTO도 목적별로 쓰는 필드만 담아서 쪼갬 어차피 DTO같은건 쿼리든 queryDsl이든 테이블이든 소스가되는 데이터 기반으로 자동 생성이 되는 시대기 때문에 생산성, 편의성보다 가독성이 훨씬 더 중요

dto 구조 설계 질문드립니다...

5개의 답변

#dto 목록