DTO 를 목적마다 생성해야 하는가

1. 의문점

과제를 진행하는 도중 기능을 추가로 구현할 수록 의문이 생겼다.

• 게시글 요청/응답
• 댓글 요청/응답
• 회원가입 요청
• 로그인 요청
• 로그아웃 요청
• 대댓글 요청/응답
• 메시지 응답

이렇게 10개의 Dto 클래스가 생겼다.

해당 기능(목적)별로 구분을 해서 구현했던 것이지만,
여기서 더 많은 기능을 구현할 경우 DTO 클래스는 더 늘어나게되는데 이게 올바른 사용법인지 궁금했다.

2. 여러 개의 DTO

목적에 맞는 필요한 필드만 가지는 DTO를 따로따로 만들 수 있다.

name 응답 DTO

@Getter
@NoArgsConstructor
public class NameResponseDto {
    private String name;
}

IdAndEmail 응답 DTO

@Getter
@NoArgsConstructor
public class IdAndEmailResponseDto {
    private Long id;
    private String email;
}

장점

• 추후 문제가 발생할 여지가 적기 때문에, 목적마다 생성하는 것이 안전하다.

• 불필요한 필드를 프론트 쪽에 노출 시키지 않는다.

• 각각의 DTO 가 유의미한 이름을 가질 수 있다.
  (즉, dto 이름만 봐도 해당 dto 의 의도가 명확하다)

단점

• 클래스의 수가 많아진다.
  • 목적마다 DTO 를 생성하는 것은 재사용/재활용 관점에서 비효율적

3. 단일 DTO

Member 응답 DTO

@Getter
@NoArgsConstructor
public class MemberResponseDTO {
    private Long id;
    private String name;
    private String email;
}

장점

• 추후 문제가 발생할 여지가 적기 때문에, 목적마다 생성하는 것이 안전하다.

단점

• 사용하지 않는 필드가 매우 많을 수 있음

  • 어떤 필드에는 null 값이 들어갈 수도 있다
  • 어떤 필드는 빈 값일 수도 있다

• 프론트 쪽에서는 사용하지 않는 필드까지도 반환받게 된다.

• DTO 가 가지는 여러 연관관계들로 인해, 불필요한 쿼리가 너무 많이 나간다.

  • 이는 최적화 관점에서 좋지 않다.

4. 결론

최적화가 필요한 서비스?

DTO 를 구분해서 여러 개 사용한다

일단 서비스 실시 가능 여부가 중요?

DTO 를 하나로 두고 빠르게 개발한다.

---

참고: DTO는 목적마다 여러개 생성해서 사용하는건가요?
참고: DTO에 관한 생각
참고: Dto 생성에 관하여
참고: DTO를 여러 개로 만들까 한 개로 만들까?