Dao와 Repository에 대해서...

우테코 레벨2 미션을 진행하면서 Dao와 Repository의 차이에 대해서 많은 이야기가 오고 가는 것을 느꼈다.

하지만 아직 Dao만으로도 충분했기 때문에 Repository에 대해서 깊게 생각해보지 않았다.

 

그런데 이번 지하철 미션에서 요구사항이 복잡해지면서 여러 Dao들이 생겼고, Repository를 써야 하는 상황이 왔다. 

페어가 제안해서 사용하긴 했지만, Repository의 필요성을 조금 느낀 것 같았다.

그래서 Dao와 Repository에 대해서 제대로 알아보기로 했다!

 

DAO란?

Data Access Object의 약자로, 데이터에 접근하는 객체이다.

웹 애플리케이션 아키텍처의 Application 계층에서 바로 데이터에 접근을 하는 것이 아니라, Dao(Persistence 계층)를 거쳐서 데이터에 접근한다.

즉, 데이터를 어떻게 저장하고 조회하는지, 무슨 데이터베이스를 사용하는지를 Application 계층은 모른다.

 

아래와 같이 Product라는 테이블에 대한 접근을 Dao를 통해서 한다.

public class ProductDao {

    private final RowMapper<Product> productRowMapper = // 생략..

    private final JdbcTemplate jdbcTemplate;

    public ProductDao(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }
    
    public int save(Product product) {
        String sqlForSave = "INSERT INTO Product (name, price, image_url) VALUES (?, ?, ?)";
        // 생략
        return keyHolder.getKey().intValue();
    }

    public void deleteById(int id) {
        String sqlForDeleteById = "DELETE FROM Product WHERE id = ?";
        jdbcTemplate.update(sqlForDeleteById, id);
    }

    public void updateById(int id, Product product) {
        String sqlForUpdateById = "UPDATE Product SET name = ?, price = ?, image_url = ? WHERE id = ?";
        jdbcTemplate.update(sqlForUpdateById, product.getName(), product.getPrice(), product.getImageUrl(), id);
    }

    public List<Product> selectAll() {
        String sqlForSelectAll = "SELECT * FROM Product";
        return jdbcTemplate.query(sqlForSelectAll, productRowMapper);
    }
}

 

이전까지는 요구사항이 간단해서 Application(Service) 계층이 하나의 Dao만을 의존하도록 구현이 가능했다.

@Service
public class ProductService {

    private final ProductDao productDao;

    public ProductService(ProductDao productDao) {
        this.productDao = productDao;
    }
    
    public int add(ProductAddRequestDto productAddRequestDto) {
        Product product = productAddRequestDto.toEntity();
        return productDao.save(product);
    }
    // 등등..
}

하나의 Dao의 접근만으로도 완전한 객체를 만들 수 있기 때문이다.

 

그런데 지하철 미션은 요구사항이 복잡하여, Line이라는 객체를 조회하기 위해서는 Section과 Station의 정보도 필요했다.

그러다 보니 서비스에서 여러 Dao를 의존하게 되었고, 조회한 객체들을 조합해서 Line을 만들어야 했다.

 

그래서 Repository 개념을 도입했다.

 

Repository란?

Eric Evans의 DDD에서 나온 개념으로, "Repository는 저장, 검색, 조회 등의 동작을 캡슐화하는 메커니즘으로, 객체 컬렉션의 추상화"라고 한다.

그리고 Patterns of Enterprise Application Architecture에서는 "도메인 객체에 액세스 하기 위한 컬렉션과 유사한 인터페이스를 사용하여 데이터와 데이터 매핑 레이어 사이를 중재한다."라고 설명한다.

 

정리하면

• 객체의 컬렉션의 추상화
• 도메인 객체에 더 가까운 상위 수준 개념
• 도메인과 데이터 액세스 계층 사이에 존재

라고 할 수 있다.

 

말로만 들어서는 이해하기 어렵다. 객체의 컬렉션의 추상화가 뭐지? 바로 다음 코드를 확인해 보자.

@Repository
public class LineRepository {

    private final LineDao lineDao;
    private final SectionDao sectionDao;
    private final StationDao stationDao;

    public LineRepository(LineDao lineDao, SectionDao sectionDao, StationDao stationDao) {
        this.lineDao = lineDao;
        this.sectionDao = sectionDao;
        this.stationDao = stationDao;
    }

    public Line findById(final Long id) {
        LineEntity lineEntity = lineDao.findById(id);
        List<SectionEntity> sectionEntities = sectionDao.findByLineId(lineEntity.getId());
        List<StationEntity> stationEntities = stationDao.findByLineId(lineEntity.getId());
        return toLine(lineEntity, sectionEntities, stationEntities);
    }
 }

Line 객체는 Section(역과 역 사이의 구간)과 Station의 정보로 이루어진 객체이다.

그래서 Line을 조회하기 위해서 LineDao, SectionDao, StationDao가 모두 필요하다.

 

이런 경우 LineService에서는 Line을 조회하는 게 목적이지, Line을 어떻게 조회하는지는 관심이 없다.

데이터베이스를 사용하는지 조차도 알 필요가 없다. 그냥 LineRepository에게 "Line을 찾아줘"라고 요청을 하고, Line을 받기만 하면 된다.

그럼 LineRepository 내부에서는 필요한 여러 Dao들을 사용해서 조립한 Line을 반환을 한다.

만약 데이터베이스를 쓰지 않고 메모리를 쓰는 InMemoryLineDao라는 Dao를 쓴다고 해도 Application 계층은 LineRepository 내부 구현과는 상관없이 똑같이 동작한다.

 

이제는 객체의 컬렉션이라는 말이 이해가 된다.

LineRepository는 Line을 조회하고 저장하는 등의 동작을 하는 Line의 컬렉션이라고 볼 수 있다.

 

이렇게 Application계층과 Persistence 계층 사이에 Repository를 둠으로써 관심사를 한 번 더 분리할 수 있다.

 

---

아직 경험이 부족해서 위의 설명이 조금은 부실할 수 있다. 조금 더 많은 경험을 해봐야 할 것 같다.

결론은 Repository를 사용해보았더니 코드도 깔끔해지고 각 레이어의 책임을 조금 더 확실하게 분리할 수 있었다. 👍

 

 

참고자료

https://www.baeldung.com/java-dao-vs-repository