Repository vs Dao

Dto는 아는데 Dao는 들어만 봤지 어떤 것인지 몰라 정리하게 되었습니다!

 

DAO

Dao(Data Access object)는 데이터에 접근하기 위한 객체로 데이터베이스 혹은 다른 영속성 매니커즘에 대한 접근을 추상화 해주는 역할

+ 영속성 : 데이터를 생성한 프로그램의 실행이 종료되더라도 사라지지 않는 데이터의 특성을 의미

 

 

어플리케이션에서 저장소에 접근하기 위해 DB 종류별로 저장소에서 제공하는 API를 통해 접근한다.

하지만 이 과정에서 문제점이 있다.

 

첫번째, 구현체와 로직이 너무 강한 결합을 가지게 된다.

만일 내가 영구 저장소를 Mysql을 쓰고 있었다고 가정해 보자. 이때 영구저장소를 Oracle로 바꿔야 한다는 요구사항이 들어왔다면, 우리는 Mysql의 API를 사용한 모든 구현을 변경해야 할 것이다. 즉, 변경에 자유롭지 않을 것이다.

 

두번째, 레이어가 깨진다.

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

 

개발자의 학습 영역이 증가

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

 

DAO

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

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

 

Repository

Repository는 과연 어느 레이어에 속할까? 공부를 조금 한 사람들은 도메인이라고 말 할 것이다.

이상하다. 우리는 보통 Repository를 DB와 같은 영구저장소를 사용하기 위해 사용하는데, 왜 도메인 레이어에 속한다고 말하는 걸까?

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

Repository가 영구저장소라는 생각을 버려라. 그냥 컬랙션이라 생각해라. 우리가 HashMap을 사용하는데 이를 Infrastructure 레이어라고 생각하는가? 아니다. 그냥 그렇게 생각해라. 객체를 위한 컬렉션일 뿐이다.

 

차이

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

?? 대체로 DAO는 DB 테이블과 1대1 매핑을 시킵니다.

 

 

 

아직 정리중인 글입니다...

ㅠㅠ 어려우ㅝ