📕 개요
DTO와 VO에 대한 궁금증이 생겨 글을 작성하였는데, 이번에는 DTO를 어떻게 작성하면 좋을지에 대한 궁금증이 생겨 블로그를 작성하고자 한다.
🤔 DTO 클래스를 어떻게 관리하면 좋을까..?
💡 Spring Boot에서 깔끔하게 DTO 관리하기
: Request에 대한 DTO, Response에 대한 DTO 등 하나의 Entity에 대해서도 여러 개의 DTO가 생기게 되고 이게 각각의 클래스로 만들다 보면 DTO 파일이 많아지는 경우를 해결하기 위해 Inner Class를 통해 이 문제를 해결하였다.
💡 DTO에 관한 생각
: Entity, DTO간 변환은 ModelMapper라는 라이브러리를 활용하여 변환, 모든 요청 응답마다 DTO를 만들 되 DTO 내부에 InnerClass를 만들어 관리
🤔🤔 매핑은 어떻게 하는게 좋을까..?
위 블로그 글 들을 보면 dto, entity간 매핑을 위해서 자바 코드 매핑, MapStruct, ModelMapper를 사용하는 것으로 보인다.
각 방식들의 문제점들을 보자면
자바 코드 매핑
- 필드의 갯수가 늘어나거나 엔티티간의 연관관계가 늘어날수록 가독성을 떨어질 것이다
- 코드를 작성하는 과정에서 개발자가 실수하여 다른 데이터를 넣을 수 있다
- 반복적인 작업으로 인해 쉽게 피로해질 수 있다
- 필드가 추가나 수정, 삭제가 일어날 경우 변환하는 로직에 대해서 수정이 필요하다
ModelMapper
- 만들어지는 대상은 Getter 만드는 대상은 Setter가 필요하다.
- Entity가 DTO로 변환된다고 한다면 Entity에는 각 필드값을 읽을 수 있는 Getter가 존재해야되고 DTO는 필드값을 넣을 수 있는 Setter들이 존재해야 한다
- 필드 작명, Standard(Default Staragy) 기준
- 필드 이름이 같을 경우 자동으로 매핑이 이루어지지만, 필드이름이 다를 경우 매핑이 이루어지지 않는다
MapStruct
- 만들어지는 대상은 Getter 만드는 대상은 Setter가 필요하다.
- Entity가 DTO로 변환된다고 한다면 Entity에는 각 필드값을 읽을 수 있는 Getter가 존재해야되고 DTO는 필드값을 넣을 수 있는 Setter들이 존재해야 한다
- 필드명이 다를 경우나 Default 값을 주고 싶을 경우
🤷 그래서 뭘 사용할까?
일단 나같은 경우는 요청별로 DTO를 외부클래스로 나누어 관리하고 자바 코드 매핑을 통해 매핑을 하고자 한다.
이유를 들자면 inner클래스 같은 경우도 결국은 해당 클래스 안에 여러 클래스를 두는 것이기 때문에 결국은 관리가 어려울 것이고 하나의 클래스에 다 몰아넣는거 자체가 나중에 유지보수 측면에서 오히려 어려울 것으로 예상되기 떄문에 DTO를 외부 클래스로 나누어서 관리하고자 하고,
자바 코드 매핑을 사용하는 이유는 아무래도 ModelMapper와 MapStruct를 사용하기 위해서는 Setter를 열어둬야 한다는 것이 제일 큰 것 같다. 아무래도 Setter를 열어두게 되면 객체의 불변성이 깨지기 때문에 예측 불가능한 동작이 이뤄질 수 있기 때문이다.
고로 나는 자바 코드 매핑을 사용하고자 한다.
