Untitled

정의

데이터베이스나 외부 파일 시스템과 같은 영속성 메커니즘에 접근하여 데이터의 CRUD(Create, Read, Update, Delete) 처리를 담당하는 객체 또는 디자인 패턴

목적 및 특징

MySQL, PostgreSQL, MongoDB 등 다양한 영구 저장소가 존재한다.

또한 이를 사용하기 위해 각 벤더별로 제공하는 API도 다양하다.

이 API를 직접 사용하게 되면 특정 영구 저장소 API에 내 코드가 종속되는 결과가 발생하게 된다.

이런 문제를 해결하기 위해, DAO는 고수준인 Business Logic과 저수준인 Persistence Logic을 분리하기 위해, Persistence Logic을 캡슐화하고 도메인 레이어에 객체지향적인 인터페이스를 제공하는 객체이다.

→ 영속성 메커니즘에 대한 CRUD 로직을 캡슐화하게 되면, Business Layer는 데이터에 접근하는 방식을 모르게 된다. (SRP 달성)

결과적으로 Business Layer는 비즈니스 로직에만, DAO는 CRUD 로직에만 집중할 수 있게 된다.

DataBase에 접근 하기 위한 로직 & 비지니스 로직을 분리하기 위해 사용

예를 들어, Business Layer에서 직접 특정 벤더의 API를 사용한 경우, Business Layer와 Database Layer(Infrastructure Layer)가 강하게 결합되고, Database Layer의 변화가 Business Layer까지 영향을 끼칠 수 있다.
만약 MySQL에서 PostgreSQL로 마이그레이션을 해야할 일이 생긴다면, MySQL의 API를 사용한 코드를 모두 PostgreSQL의 API를 사용한 코드로 변경해야하는 등의 문제도 발생할 수 있을 것 이다.

Business Layer는 Business Logic에만, DAO는 CRUD 로직에만 집중할 수 있게 된다.
DB가 바뀌더라도 Business Logic은 유지한채로, 코드의 큰 수정없이 변경 가능
HTTP Request를 Web Application이 받게 되면 Thread를 생성하게 되는데 비즈니스 로직이 DB로부터 데이터를 얻어오기 위해 매번 Driver를 로드하고 Connection 객체를 생성하게 되면 많은 커넥션이 일어나므로 DAO를 하나만 만들어 DB 전용 객체로만 쓰는 것

repository는 엔티티 객체를 보관하고 관리하는 저장소이고, dao는 데이터에 접근하도록 DB접근 관련 로직을 모아둔 객체
DAO는 Data Peristence의 추상화이고, Repository는 객체 Collection의 추상화이다.
DAO는 storage system에 더 가까운 개념이고 상대적으로 low level concept, Repository는 Domain객체에 가까운 개념이며 상대적으로 high level concept
DAO는 데이터 매핑/접근 계층으로 쿼리를 숨기지만, Repository는 Domain과 DAL사이의 계층으로 데이터를 대조하고 Domain 객체로 Mapping하는 로직을 숨긴다.
DAO는 Repository를 사용하여 구현할 수 없지만, Repository는 DAO를 사용해 구현할 수 있다.
Data Access한다는 점에서 Repository와 DAO는 공통점을 갖지만, Repository는 객체 중심, DAO는 데이터 저장소(DB 테이블) 중심인 것이다.
또한, Repository는 객체 중심으로 데이터를 다루기 위해 하나 이상의 DAO를 사용할 수 있으며, 따라서 DAO보다 higher layer이다.
DAO는 영속성 객체를 숨기지 않는다. 구현체가 인프라 계층에 있다는 것을 숨기지 않는다.
Repository는 영속성 객체임을 숨긴다. 구현체가 인프라 계층에 숨겨져있다.
Repository는 인터페이스이며, 도메인 계층에 속한다.