객체 디자인 패턴, DAO & DTO & VO

서버사이드에서 개발하다보면, 객체 컨벤션이 중요하다고 느끼는 시점이 온다.(내가 그 시점인 것 같다..)

 

가장 먼저 눈에 띄는건 DAO, DTO, VO인데, 세 가지의 객체의 분류가 꽤나 애매하다. 따로 표준화 되어 있지도 않고 POJO라고 불리는 일반적인 자바 객체로 만들어지기 때문이다.

 

간단하게 내용을 한번 정리하고 가보려 한다.

1. DAO(Data Access Object)

사실 DAO의 역할은 명확하다. 이름부터가 Data Access Object인 것을 보면 알 수 있듯이, 실제로 DB에 접근하는 역할을 하는 객체 생성 디자인 패턴이다.

 

데이터베이스에 추출 및 저장하는 방법에 대한 세부 정보를 객체로 추상화하는데 사용되며 JDBC를 통해 구현할 경우 CRUD를 처리하는 매서드를 가지고 있는 경우도 있다.

위와 같은 경우 일반적인 객체가 아닌 좀 더 복잡하게 구현된 객체로서 DB와 백엔드를 연결하는 레이어의 역할을 하게 된다.

이와 다르게 DB의 CRUD 결과를 단순히 매핑하는 역할을 할 경우는 POJO로 생성되어 사용된다.

2. DTO(Data Transfer Object)

가장 역할이 애매한 객체가 DTO다. 일반적으로는 어플리케이션 내에서 서로 다른 계층 간 데이터를 전송하는데 사용되는 객체 생성 디자인 패턴이다.

 

위 그림처럼 계층을 단순화 했지만, 실제 어플리케이션은 더 세분화된 계층을 갖고, 데이터를 전송하는 일도 잦기 때문에 비교적 자유롭게 사용하는 객체라고 생각된다.

 

3. VO(Value Object)

VO는 변경 불가능한 객체를 나타내는 데 사용되는 객체 생성 디자인 패턴이다. 일반적으로 날짜, 통화 또는 수량을 나타내는 데 사용된다.

VO 객체는 일반적으로 자주 변경되지 않고 단일 단위로 전달될 수 있는 데이터를 나타내는 데 사용된다. 예를 들어 Client에서 보내주는 Request는 백엔드에서는 변경할 일이 없다. 이럴 때, Request를 VO 형태로 받을 수 있다.

하지만 VO로 받아야 될 것을 DTO나 DAO로 받아도 문제가 되느냐? 는...

 

4. 그래서 어떻게 쓰는게 맞는데?

사실 명확한 구분은 없다. 명확한 구분도 없을 뿐더러 엄격하게 나누지도 않는다.

 

개발자마다 객체를 구분하고 정의하는 스타일이 다르기 때문에 DB에서 데이터를 꺼내올 때 DTO를 쓰는 경우도 있고, VO를 쓰는 경우도 있다. 또 VO를 불변으로 쓰지 않는 경우도 정말 많다.

 

때문에 개발을 시작하기 전, 사전 정의가 정말 중요하다. 아니면 다양한 사람 손을 거치며 남겨진 통일성 없게 정의된 객체들을 마주하게 될 것이다.

 

5. 마치며

여러 사람 손을 거치면서 중구난방으로 만들어진 객체들을 보면 어떤 생각을 하면서 정의했길래 이렇게 만들어 놨을까? 란 생각이 좀 들어, 작성해 본 내용이다. 결론은 알아서 잘하자 이지만, 알아서 잘 할 수 있도록, 개발 문서 같은게 좀 남겨져 있었으면 좋겠다..