REPOSITORY vs DAO

0. 서론

이전에는 DTO vs VO vs Entity 그리고 POJO 의 차이에 대해 알아봤었다.

이번에는 REPOSITORY 와 DAO의 차이에 대해 알아보려 한다.

이전 Spring MVC 를 사용할 때는 DAO는 데이터베이스를 연결하는 개체 정도로만 알고 사용하여, 이곳에 SQL문을 넣어 사용하였다.

하지만 JPA를 익히면서 DAO 와 차이에 대해 의문을 가지게 되었다.

사실, 두 객체의 인터페이스의 차이는 크게 없다고 한다.(그렇게 생각 됌). 하지만 혼용을 하여 사용하는것은 논쟁의 불씨를 남기는것이기에,,

그래서 이번장에 다시한번 이걸 정리하고 넘어가려 한다.

1. DAO VS REPOSITORY

DAO / REPOSITORY 정리

• DAO는 data persistence의 추상화.
• DAO는 데이터베이스와 관련이 많으며 Table 중심
• REPOSITORY는 Collection of Objects의 추상화
• REPOSITORY는 도메인과 관련이 있으며, Arggregate Roots만을 다룬다.
• REPOSITORY는 여러 DAO를 통해 구현이 가능하지만, 그 반대는 불가.
• REPOSITORY는 보통 한정된 인터페이스이다. 단순히 Get(id), Find(Specification), Add(Entity) 와 같은 객체들의 Collection이다.
• UPDATE 같은 메서드는 DAO에 적합하며 REPOSITORY와는 맞지 않는다.
• 실제로 흔히 REPOSITORY라고 부르지만 DAO에 가까운 것들이 많다.

• 둘다 쿼리를 다룬다는것에 비슷하지만 DAO가 REPOSITORY보다 조금 더 유연한 패턴이다. 만약 둘다 사용하고 싶다면 DAO에서 REPOSITORY를 사용한다.

• REPOSITORY 는 특정 타입의 저장소이다 , 특정 타입의 객체들을 찾을수 있고 저장할 수 있다. 보통 객체들의 한가지 타입만을 다룬다.

  List<User> findAll(Creteria creteria);
  User save(User user);
  

• DAO는 데이터를 저장한다. 같은 데이터 타입인지 아닌지는 크게 상관하지 않는다 , 따라서 관련된 데이터를 저장하는 DAO를 별 제약없이 쉽게 생성하는 것이 가능하다.

  // UserDao
  Collection<Permission> findPermissionsForUser(String userId)
  User findUser(String userId)
  Collection<User> findUsersForPermission(Permission permission)
  

• DAO와 REPOSITORY 모두 DAL(DATA ACCESS LAYER) 의 구현체 ``` DAL(Data Access Layer).

DB와 연결된 객체지향 어플리케이션들은 반드시 DB관련 정보들을 처리해야함 그러기 위해선 그 코드들을 깔끔하게 모듈화 해야한다.

Layerd Architecture에서 이 모듈이 DAL 이다.

스프링은 Hibernate를 사용하여 이 DAL를 모듈화 하고 그것이 바로 DAO ㅠㅐ턴이다.

그럼 Repository는 어떨까? DAO와 비슷하게, Repository 또한 DAL를 구현하는 방법 중 하나이다. 이 패턴의 중요한 점은 사용자의 관점에서의 collection처럼, 보고 행동해야 한다는 것이다. ```

• 즉 DAO와 Repository의 차이는 DAL를 구현하는 방식의 차이 이다.