DAO, DTO, VO

어디선가 본 단어들이다.. 특히 DAO DTO는 Spring 공부 하면서 나왔던 기억이 있다.

DAO는 Repository라는 것이 생각난다. 이번에 세가지를 자세히 조사해본다.

DAO

컴퓨터 소프트웨어에서 데이터 접근 객체(data access object, DAO)는 일부 종류의 데이터베이스나 기타 퍼시스턴스 매커니즘에 추상 인터페이스를 제공하는 객체이다. 응용 프로그램의 호출들을 퍼시스턴스 계층에 매핑시킴으로써 DAO는 데이터베이스의 상세한 사항을 노출시키지 않고 특정 데이터의 일부 동작을 제공하게 된다. 이러한 분리는 단일 책임 원칙을 지원한다. 도메인 특화 객체 및 자료형(DAO의 퍼블릭 인터페이스) 관점에서 응용 프로그램이 필요로 하는 데이터 접근이 무엇인지를, 어떻게 이러한 요구사항을 특정 DBMS, 데이터 스키마 등을 만족할 수 있는지(DAO의 구현체)와 분리시킨다.

이번에도 위키백과를 본다.

위키백과에선 몇가지 중요하게 볼 부분이 있는데 아래와 같이 정리 가능하다.

DB나 persistence 매커니즘에 추상 interface를 제공하는 객체이다.
- 이전 시간에 배웠던ORM이 떠오른다. 즉 DAO는 데이터에 접근하는 객체를 말하며 RDB와 연결 될 때는 ORM과 같은 맥락의 객체가 된다.
persistence 계층에 매핑 시킴으로 DAO는 DB의 상세 사항을 노출하지 않고 데이터의 동작을 제공한다.
- 이 또한 ORM과 비슷하다고 할 수 있으나 데이터의 접근 관점에서 중요 데이터 등을 직접 사용하는 것이 아니라 DB로 분리, 매핑해서 상세 사항을 숨길 수 있다.
응용프로그램이 필요로 하는 데이터 접근이 무엇인지, 이런 요구사항을 DBMS, 스키마 등을 만족할 수 있는지와 분리한다.
- 즉, 실제 서비스 되는 모델과 DB를 연결하면서 여러 사항을 고려하면서 작성되는 객체라는 의미이다.

DAO와 Repository 모두 퍼시스턴스 로직에 대한 객체지향적인 인터페이스를 제공한다는 점에서 공통사항이 있다.

중요한 부분 중 하나는 둘 모두 도메인의 동작과 퍼시스턴스의 동작을 분리하여 관심의 분리 원칙을 만족 시키는 데에 목적이 있다. 이는 곧 관점 지향 프로그래밍(AOP)와도 연결된다.

하지만 둘에 차이점도 존재하기 때문에 아래에 정리해봤다.

데이터 전송 객체(data transfer object, DTO)는 프로세스 간에 데이터를 전달하는 객체이다. 프로세스 간 통신이 일반적으로 원격 인터페이스(예: 웹 서비스)로 재정렬하면서 이루어지게 되는데 여기에서 각 호출의 비용이 많다는 점을 동기로 하여 이용하게 된다. 각 호출의 비용이 큰 것이 클라이언트와 서버 간 왕복 시간과 관련되기 때문에 호출의 수를 줄이기 위해 여러 호출에 의해 전송되는 데이터를 축적하면서 오직 하나의 호출만으로 서비스되는 객체인 DTO를 사용하는 것이다.

이 또한 위키백과에서 중요한 부분이 몇개 보여 간추려보았다.

프로세스 간 데이터를 전달한다.
- 데이터 전달을 목적으로 하기 때문에 로직이 있지 않고 순수 데이터의 객체이다.
인터페이스로 재정렬된 통신의 호출에 비용이 많이 든다는 점을 보고 이 호출의 수를 줄이기 위해 여러 호출에서 전송되는 데이터를축적해 하나의 호출로 서비스되도록 한다.
- 즉, 데이터에 접근 할 때 호출이 많아져 느려지니 실제로 DB에서 호출된 데이터가 여러 층을 지나는데 이 때 여러 층 간 데이터를 교환할 때 사용하는 객체이다.

DTO의 개념을 보면 Entity와 공통되는 부분들이 있다.

물론 이 DTO나 Entity가 데이터에 직접 접근 하는 것은 아니기 때문에 이렇게 지정되고 수정된 데이터가 DB에 반영되도록 도와주는 것은 Repository, 즉 DAO이다.

vo는 Value Object의 약자로 말 그대로 순수 값을 나타낸다.

그럼 DTO와 같은 거 아닌가? 라고 생각이 들지만 VO는 순수 값을 나타내는 객체로 읽기만 되는 객체이다. 즉, 값이 한 번 지정되면 수정 할 수 없는 객체인 것이다.

위에서 말했듯 차이점이 존재 하는데 정리해보자면 아래와 같다.

프로그래밍을 잘하고 싶어요..