Repository 사용기

지금까지 Dao를 이용하여 영속성 계층과 서비스 계층 간 소통을 해왔다. 이렇다 보니 서비스 단에서 해야할 일이 많았다. 코드가 길어지고 가독성이 떨어지는 것 같아 Repository를 통해 그 역할을 분리해서 사용해보았다.

---

Dao

Dao는 Data Access Object의 약자이며 데이터에 접근하는 객체이다. Dao를 거쳐서 데이터에 접근하기 때문에 상위 계층에서는 DB의 구조, 사용법 을 몰라도 된다.

Repository

Repository는 흔히 저장, 검색, 조회 등의 동작을 캡슐화하는 메커니즘으로, 객체 컬렉션의 추상화 로써 표현한다.

이는 처음 보았을 때 너무 어려웠다. 내가 생각한 Repository는 다음과 같다.

내가 주문을 저장한다고 해보자.

이럴 때 주문도 저장해야하고, 주문에 사용한 쿠폰도 저장해야하고, 카트 바구니도 변경되어야하고, 주문 상품도 저장되어야한다.

Repository라는 중간계층이 없다면 이 모든것을 service에서 처리해야한다. 하지만 Repository라는 주문저장 에서 모든 것을 처리하고 반환한다면 service는 저장 하라는 요청을 보내고 저장되었다는 반환만 받는 것이다.

주문 저장에 대해 함께 처리되어야할 것들에 대해 처리하는 것이다.

이는 주문을 저장, 조회, 삭제 하는 등 주문 객체 컬렉션 이라고 볼 수 있다고 생각한다.

---

레포지토리는 어떻게 나누어야 하는가 ?

이번 미션에서 처음 레포지토리를 분리해보았기에 어떻게 구성되어야 하는지에 대해 잘 알지 못하였지만 해보았다.

먼저 domain 계층에 Repository 인터페이스를 두고 영속성 계층에 Repository 구현체를 두면서 계층간 분리를 하는 방식을 위해 분리하였다. 꼭 이렇게 할 필요는 없지만 나는 계층간 분리를 해보고 싶어서 시도를 해보았다.

처음에는 모든 dao에 대해 레포지토리를 생성하고 사용하였는데 이는 더 복잡함만을 주었다. 연결테이블Dao에 대해서도 repository를 만들었기 때문이다.

리뷰어 제이미의 의견을 듣고 repository 영역은 영속화를 위해 함께 조회,저장 등이 이뤄지는 여러 도메인 객체들을 관리하는 책임이 있다고 생각하여 영속화를 위한 작업만 거쳐야 된다고 생각하게 되었다. 그래서 위에 보이는 Repository만 존재하게 되었다.

검증 로직

Repository에서 객체를 만들기 위한 과정중에 검증도 진행을 하였었다. 이는 비즈니스 로직이라고 생각되어 서비스 영역에 두는 것이 맞다고 생각하게 되었다. Repository 영역을 사용한다면 Repostiory영역의 책임만 주는것이 옳다고 생각한다.

---

결과

Repository를 분리함으로써 서로 역할 분리가 잘 되었고 리팩토링 하기가 훨씬 수월해 졌다.

데이터와 연관된 부분은 Repository와 Dao를 확인함으로써 이해하기가 훨씬 쉬웠다.