티켓 프로젝트를 진행하다가 다들 DTO에 대한 처리방식이 있었는데 나도 하나 적고 싶어서 DTO에 대한 내용을 찾다가

DTO에 관한 고찰
이분에 대한 내용 글이 재미있어서 읽고 블로그에 정리하고 싶어졌다.

DTO 란?

Data Transfer Object 로 계층간의 데이터를 교환하기 위한 자바 Beans를 말한다고 한다.

속성과 속성에 접근하기 위해 getter와 setter를 사용한다고 말한다.

VO 란?

값 자체를 표현하는 객체( 특정한 값을 나타내는 객체 )
서로 다른 이름을 가진 VO 인스턴스가 모든 속성 값이 같다면 같은 객체이다. (equals(), hashCode()을 Overriding 해줘야 한다.)
객체의 불변성을 보존한다.
로직을 포함할 수 있다.

DTO == VO ?

DTO를 VO 처럼 불변 객체로 사용하면?
-> DTO가 전송하고자 하는 데이터가 전송 과정 중에 변조되지 않음을 보장한다.

Entity

실제 DB의 테이블과 매핑되는 클래스
Id로 구분
로직을 포함할 수 있다.

Entity를 DTO로 사용하면 안되나?

사용할 순 있지만, View에서 표현하는 속성 값들이 요청에 따라 계속 달라질 수 있는데 그때마다
Entity의 속성 값을 건들면 영속성 모델로 표현한 Entity의 순수성이 모호해져서 Controller에서
쓸 DTO와 Entity 클래스를 분리하는게 좋다.

DTO를 쓰는 이유

테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 미치기 때문에
MVC의 View와 통신하는 DTO 클래스는 자주 변경되므로 분리한다고 한다.
또한 Entity에서 원하는 데이터만 추려서 View에 전송할 수 있다.

DTO를 어떻게 사용할 것인가

• 어디부터 어디까지 DTO를 사용할 것인가

Data Transfer Object는 계층 간 이동을 위해 만들어진 객체이므로 직접적인 Entity를 사용하자는
Repository 전까지 즉, Clinet - Controller - Service 이 세가지 계층을 오고 갈 때 사용하는 것이 맞다
생각한다.

• Entity 와 DTO 간의 변화는 어떻게 진행할 것인가

Entity와 DTO 간의 변화는 생성 될 인스턴스 변수에 직접 값을 넣어주는게 맞다 생각하고 이때 ModelMapper 사용으로 유지보수에 힘을 실어준다.

• 어떻게 만들 것인가

원래는 그냥 그에 맞게 함수 만들어 줄까 생각 했었는데, 링크 건 블로그 내용에 Entity에서 DTO는 static of(엔티티) 형식에 ModelMapper를 사용하는 것을 보고 저렇게 적으면 나중에 변화에 유연한 대처가 가능하다 생각해서 저렇게 적고 DTO에서 Entity는 builder를 사용한다고 말하는데 나는 ModelMapper를 활용해
toEntity(DTO) 안에서 반대로 ModelMapper.map(DTO, Entity.class) 형식을 사용하면 어떤가 생각한다.

또한 링크를 걸은 블로그 필자는 class 안에 static class로 만들어 사용한다고 하는데 나는 작업하면서 한 클래스 안에 inner class가 많으면 찾기 어려운 것과 보는 것에서 불편하다 느껴 유연하게 사용하는게 낫다 생각한다.

거의 블로그 내용을 붙인 내용도 많지만 나에 대한 생각도 여럿 적어보니 좀 뿌듯하기도 하다.