DTO는 어떻게 관리하는게 좋을까? 에 대한 고민과 해결책

현재 직장에서 진행 중인 프로젝트에서 고민이 생겼다.

이전에 개인적으로 팀 프로젝트를 진행했을때는 Req,Res 클래스를 매번 만들어 도메인 별로 관리를 했다.
그러나 실무에서 적용할 때는 가급적 관리할 클래스 수를 줄이고 싶었고, 중복코드를 줄이고 싶었다.
그렇게 고민 끝에 세가지 방안을 내놓게 되는데 ....
(사실 서버단은 나 혼자이기 때문에 혼자 먼저 고민한 후 최종으로 클라이언트단과 합의하여 결정했다.)

1.목적마다 DTO를 생성한다

장점

• 목적에 맞고 필요한 필드만 가지는 DTO를 생성
• 추후 문제가 발생할 여지가 적음
• 불필요한 필드를 프론트 쪽에 노출 시키지 않음
• 각각의 DTO가 유의미한 이름을 가짐(이름으로 의도 파악 가능)

단점

• 클래스의 수가 많아짐
• 중복된 코드 다수 발생
• 재사용이 어려움
• 클래스 수가 많아질수록 네이밍이 어려워짐

 

2.최대한 추상화(공통화)하여 클래스의 갯수를 줄인다

장점

• 단일(공통) DTO를 사용하면 중복 코드와 클래스 갯수를 줄일 수 있음

단점

• 불필요한 필드가 프론트쪽에 노출됨
• 사용하지 않는 필드가 많다 (null 등의 의미없는 값)
• DTO 끼리 연관관계 때문에 불필요한 쿼리 발생

 

3.공통 클래스를 만들고 Inner class를 만들어 활용한다 - 채택

장점

• 클래스 갯수를 줄일 수 있음
• 하나의 공통된 클래스 안에 Inner class들을 생성하여 관리가 편함
• DTO 목적이 명확하도록 네이밍 가능

단점

• 내부 클래스에도 여전히 중복된 필드가 발생 (중복코드)

 
3번 방안을 채택했지만 여전히 중복된 코드가 발생했는데 이는 2번의 추상클래스 사용으로 해결했다.

결과

2개의 엔티티에 관련된 DTO 클래스를 12개에서 2개로 줄였고 중복 코드도 대폭 줄여 코드 관리가 편해졌다.

이렇게 DTO를 관리하는 방법에는 정답이 없다.
프로젝트의 규모, 구조와 클라이언트단과의 소통을 통해 적절한 해결책을 채택해보자!