우리가 데이터베이스를 접하면 꼭 알아두어야할 DTO, DAO, VO에 대해 알아보도록 하자. 우선 첫번째 DTO는 무엇일까?
DTO는 Data Transfer Object는 계층 간 데이터 교환을 하기 위해 사용하는 객체로, DTO는 로직을 가지지 않는 순수한 데이터 객체라고 한다. 또 DB에서 꺼낸 값을 임의로 조작할 필요가 없기 때문에 DTO에서는 Setter을 만들 필요 또한 없고, DTO클래스에서는 생성자에서 값을 할당하게 된다고 한다.
Request와 Response용 DTO는 View를 위한 클래스 역할을 하기도 한다. 이는 자주 변경이 필요한 클래스를 말하는데 toEntity 메소드를 통해서 DTO에서 필요한 부분을 이용하여 Entity로 만들고 Controller Layer에서 Response DTO 형태로 Client에 전달하게 된다.
위의 이미지는 DTO와 밀접하게 관련이 있는 MVC패턴이다.
DAO는 데이터 베이스의 data에 접근하기 위한 객체라고 한다. 데이터 베이스에 접근하기 위한 로직과 비지니스 로직을 분리하기 위해 주로 사용한다고 한다.
VO는 값 오브젝트라는 뜻으로 값을 위해 쓰인다고 한다. 무슨소리인가 하니 ready only 특징(오직 읽어들이기만 가능하고 수정X)을 갖는다고 한다.
그렇다면 VO와 DTO의 차이가 무엇일까?
VO는 DTO와 동일한 개념이지만 read only 속성을 갖고, VO는 특정 비즈니스 값을 담는 객체이고 DTO는 Layer간의 통신 용도로 오고가는 객체를 말한다는 부분이 다른 부분으로 작용된다. 또한 DTO 클래스는 Setter을 가지고 있기에 값이 변할 수도 있다는 부분이 다른 점으로 작용된다.
Entity Class는 실제 DB의 테이블과 매칭될 클래스를 뜻한다고 한다. 최대한 외부에서 Entity 클래스의 getter 메소드를 사용하지 않도록 해당 클래스 안에서 필요한 로직 메소드를 구현하게 되는데 이때 도메인 로직만 가지고 있어야하고 프로젠테이션 로직을 가지고 있어서는 안된다고 한다.
왜 Entity클래스와 DTO 클래스를 분리하는 것일까?
View Layer와 DB Layer의 역할을 철저하게 분리하기 위해서 라는 이유가 첫번째로 있다. 그리고 테이블과 맵핑되는 Entity클래스 특성상 데이터가 변경되면 여러 클래스에 영항을 끼치게 되기에, 자주 변경되는 View와 통신하는 DTO클래스와는 분리가 필요하다고 볼 수 있다.
도메인 모델을 아무리 잘 설계했다고 해도 각 View내에서 도메인 모델의 getter만을 이용해서 원하는 정보를 표시하기가 어려운 경우가 종종 있는데 이런 경우 모델링의 순수성을 깨고 도메인 모델 객체를 망가뜨리면서 로직을 추가하거나 수정해야하는 경우가 생기기 때문이라는 이유가 있기도 하다.
또 마지막으로 도메인 모델을 복잡하게 조합한 형태의 프레젠테이션 요구사항들이 존재하기에 도메인 모델을 직접적으로 사용하는 것은 어렵다고 볼 수 있다. 이러한 이유들로 인해 우리는 DTO와 Entity 클래스를 분리해서 사용해야할 것이다.
참고자료
https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html
https://melonicedlatte.com/2021/07/24/231500.html