[Spring] DTO 구조를 어떻게 구성해야할까

dto 구조를 어떻게 구성해야할지 고민을 정말 많이 했다.

나의 방법이 정답이 아니지만 나와 같은 고민을 하는 분들을 위해 고민을 기록해본다.

 

 

😓 고민의 서막

 

프로젝트를 진행하면서 많은 dto 가 만들어졌다.

그래서 처음에는 비슷한 dto 객체들을 InnerStaticClass 를 사용하여 생성하였다.

 

우선 InnerStaicClass 를 알아보자

 

 

🔍InnerStaicClass

 

내부 클래스를 사용하는 이유

• 외부 클래스와 내부 클래스가 긴밀한 관계를 맺을 때 사용한다.
• 내부 클래스에서 외부 클래스의 멤버에 쉽게 접근할 수 있다.
• 서로 관련있는 코드를 묶어서 코드의 캡슐화를 증가시킨다.
• 외부에서는 내부 클래스에 접근할 수 없기 때문에 코드의 복잡성을 줄일 수 있다.

static이 붙지 않았을 때 단점

• 참조값을 담아야 하기 때문에, 인스턴스 생성시 시간적, 공간적으로 성능이 낮아진다
• 외부 인스턴스에 대한 참조가 존재하기 때문에, 가비지 컬렉션이 인스턴스 수거를 하지 못하여 메모리 누수가 생길 수 있다.

Static inner class를 생성할때는 일반적인 static 멤버에 접근할때와 같이 클래스명.멤버명으로 접근해서 생성한다.

Instance inner class와 달리 outer class의 인스턴스를 생성하지 않아도 된다.

 

 

dto 수가 많지 않다면 InnerStaticClass로 간단하게 생성해도 좋다.

하지만 dto 수가 많다면 코드의 가독성과 확장성에 문제가 될수도 있다.

따라서 나는 builder 패턴으로 변경하기로 했다.

 

 

🔍Builder 패턴

 

Builder 패턴의 장점

• 각 인자의 의미를 알기 쉽다.
• 플루언트 API 또는 메서드 체이닝을 한다.
• setter 메소드가 없으므로 변경 불가능(immutable) 객체를 만들 수 있다. 
• 한 번에 객체를 생성하므로 객체 일관성(consistency)이 깨지지 않는다.
• build() 메소드에서 잘못된 값이 입력되었는지 검증할 수 있다.
• 객체 생성에 관련된 코드를 보다 명확하고 확장 가능하게 만들 수 있기 때문에 코드의 가독성을 높이고 유지보수에 용이하다.
• 계층적으로 설계된 클래스와 함께 사용하기 좋다.
• 점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결하고, 자바빈즈 보다 훨씬 안전하다.

단점

• 일부 필드의 값을 안넣어도 필드가 Null로 들어가면서 객체가 생성가능하여, 개발자가 필수적으로 설정해야 하는 필드를 빠트릴 수 있다.
• 빌더 패턴을 사용하면 일부 필드를 불변으로 만들 수 없다. 즉, 빌더를 통해 생성된 객체의 일부 속성이 변경될 우려가 있다.
• 빌더 패턴을 구현하려면 추가적인 빌더 클래스가 필요하므로 클래스 수가 늘어나게 된다.

 

단점이 클래스수가 늘어난다는것인데... 그래도 유지보수에 용이하니깐 builder 패턴으로 dto 를 생성했다.

근데 프로젝트가 진행될수록 dto 수가 대략 30개 정도로 늘어났다...

이게 맞아...?ㅎ

 

 

🫠 계속되는 고민..

 

현재 문제점

Builder 패턴으로 생성해서 너무 많은 dto 클래스가 만들어졌다.

줄일수 있는 방법이 있나??

 

고민한 방법

1. SuperBuilder 사용
   • @SuperBuilder 란?
     • 부모 클래스의 필드도 포함하여 빌더를 생성할 수 있게 해준다. 즉, 부모 클래스의 필드 또한 빌더에 포함되어 생성할 수 있다.
   • 단점
     • 상속할때 여러 부모 추상클래스를 상속할수 없다.
     • 어떻게든 각 부모 추상 클래스를 만들어줘야한다 -> 필드의 중복만 해결해주므로 현재 dto 클래스 수를 줄일수없다.
     • 서비스단에서 객체 생성이 가능하다 -> 코드 작성이 늘어난다.
2. Mapstruct 사용
   • Mapstruct 란?
     • 객체 간의 매핑을 간편하게 수행할 수 있도록 도와주는 라이브러리
     • 어노테이션을 이용하여 매핑 대상 객체의 필드와 관련된 메서드를 생성해주어 반복적이고 일상적인 매핑 코드 작성을 줄이고 유지보수성을 향상시킬 수 있다.
   • 단점
     • 매핑할려는 객체와 필드값이 같지않으면 추가로 구현 코드를 작성해야한다. -> 현재  여러 dto가 있는 상황에서는 복잡해 보일 가능성 높다.

 

 

현재 나의 상황에서는 둘다 탈락...ㅎ

 

 

🤯 고민은 진행중...

 

똑똑한 개발자분에게 도움을 청했더니 실무에서는 dto 클래스가 엄청 많다고 해서 괜찮다고 하셨다.

그래서 우선 지금은 빌더 패턴을 사용해서 객체를 생성하는 구조로 구현하고 있다.

dto 수는 계속 늘어나고 있지만 아무쪼록 잘 정리해봐야겠다.

현재 dto 구조

 

 

 

아직도 계속 더 좋은 방법이 있는지 찾아보고 있다..

더 좋은 방법을 발견하면 추가로 올리겠다.

 

(혹시라도 좋은 방법이 있다면 추천해주시면 감사드리겟슴니다!!😊)