DAO와 Repository 차이

영구 저장소 API 문제점

우리는 MySQL, Oracle, MongoDB 등 다양한 영구 저장소의 구현체를 사용해왔다. 그리고 어플리케이션에서 이러한 저장소에 접근하기 위해 벤더별로 저장소에서 제공하는 API를 통해 접근해왔다. 이 과정에서 어떤 문제가 있었을까.

 

구현체와 로직의 강한 결합 문제

만약 MySQL과 같은 특정 벤더의 영구 저장소를 사용하고 있을 때, Oracle로 변경해야 한다면 MySQL의 API를 사용한 모든 구현을 변경해주어야 하는 불편함이 생긴다.

 

계층 간 간섭 문제

레이어가 깨지는 문제는 결국 강한 결합 문제로 연결된다. MySQL의 API를 서비스 로직에서 사용했을 경우, 서비스 로직과 DB와 관련된 API가 강한 결합을 가지게 되어 영속성과 관련된 로직이 서비스 로직에 영향을 미치는 문제가 발생한다. 즉, 서비스 계층과 인프라 계층(영속성 계층)간의 결합이 강해지는 문제가 생긴다는 것이다.

 

개발자의 학습 영역이 증가

각 저장소는 벤더별로 특징이 모두 다르다. 따라서 그 특징마다 다른 구현을 가지기 때문에 개발자의 학습영역은 증가할 수밖에 없다.

 

DAO

위의 문제들을 해결하기 위해 나온 것이 바로 DAO 패턴이다. DAO패턴은 벤더들의 API와 로직 사이에 있는 어댑터와 같은 역할을 수행한다.

DAO가 어댑터의 역할을 수행하기 때문에 벤더의 구현체를 그대로 사용하지 않고 DAO객체를 이용하여 데이터 소스가 변경되더라도 그 로직에는 변화가 없도록 하는 강한 결합 문제를 해결했고, 각 벤더 별 구현의 차이점을 극복했다는 점에서 개발자의 학습 영역에 대한 부담감을 덜 수 있었다. (레이어가 깨지는 문제점은 각 계층 간 전달되는 데이터 객체인 DTO를 만들어 해결)

 

Repository

Repository는 객체의 상태를 관리하는 저장소이다. 즉, Repositoty는 영구 저장소를 의미하는 것이 아니고 객체의 상태를 관리하는 저장소라는 것이다. 따라서 도메인 정보를 가지고 있어야 하는 Repository는 인프라 계층이 아닌 도메인 계층이라는 점이다.

 

따라서 차이는

DAO와 Repository는 구현체가 보이냐 안 보이냐의 차이이다.

• DAO는 영속성 객체를 숨기지 않는다. 구현체가 인프라 계층에 있다는 것을 숨기지 않는다.
• Repository는 영속성 객체임을 숨긴다. 구현체가 인프라 계층에 숨겨져 있다.
• Repository는 인터페이스이며, 도메인 계층에 속한다.

참고 : https://velog.io/@maketheworldwise/DAO%EC%99%80-Repository%EC%9D%98-%EC%B0%A8%EC%9D%B4

 

 

DAO vs Repositroy

• DAO는 Data Peristence의 추상화이고, Repository는 객체 Collection의 추상화이다.
• DAO는 storage system에 더 가까운 개념이고 상대적으로 low level concept, Repository는 Domain객체에 가까운 개념이며 상대적으로 high level concept
• DAO는 데이터 맵핑/접근 계층으로 쿼리를 숨기지만, Repository는 Domaun과 DAL사이의 계층으로 데이터를 대조하고 Domain 객체로 Mapping하는 로직을 숨긴다.
• DAO는 Repository를 사용하여 구현할 수 없지만, Repository는 DAO를 사용해 구현할 수 있다.

또한, Repository는 객체 중심으로 데이터를 다르기 위해 하나 이상의 DAO를 사용할 수 있으며, 따라서 DAO보다 higher layer이다.

 

참고 : https://isaac56.github.io/etc/2021/08/29/difference_DAO_Repository/