그림-01을 보면서 문득, MVP, MVVM에서 Repository 를 사용하는데… 그래서 Repository가 뭘까? 생각이 들었다. MVP와 MVVM에 대한 다양한 예제들을 참고하며, Repository가 있는 예제도, 없는 예제도 많이 보며 공부했고, Repository 역할이 데이터를 호출에 대한, 즉, 관심사를 분리하기 위한 용도로 사용한다고 인지는 하고 있었지만, 그래서 뭘까? 하는 생각이 들었고, 이 글을 쓰게 되었다.
왜 나온걸까?
프로그램의 핵심인 비즈니스 로직이 얼마나 잘 짜여졌는지에 따라 결과가 다르게 나올 것이다. 이 비즈니스 로직은 보통 외부 데이터베이스(Remote)나 앱 내 데이터베이스(Local)에 접근하게 되는데, 이 과정에서 여러 문제(중복 코드, 오류 코드 등)가 발생할 수 있다.
이러한 문제를 해결하기 위한 방법으로는, 첫 번째는 비즈니스 로직과 데이터 레이어를 분리하는 것이며, 두 번째는 중앙 집중 처리 방식을 통해 일관된 데이터와 로직을 제공하는 것이다.
그래서 Repository Pattern이 뭔데?
위 두가지 문제 해결 방법을 토대로 나온 것이 Repository Pattern이다. “저장소”라는 뜻을 가진 Repository는 데이터 소스 레이어와 비즈니스 레이어 사이를 중재하는 역할을 한다. 데이터 소스에 쿼리를 날리거나 데이터를 다른 domain에서 사용할 수 있도록 새롭게 매핑할 수 있다.
그래서 어떻게 사용되는데?
데이터가 있는 저장소인 RemoteDataSource와 LocalDataSource를 추상화하여 중앙 집중 처리 방식을 구현한다.
데이터를 사용하는 도메인에서 비즈니스 로직에만 집중할 수 있다. ex) ViewModel에서는 데이터가 Local DB에서 오는지, 서버 API를 통해 오는지 알 필요가 없다. Repository를 참조해 제공하는 데이터를 이용하기만 하면 된다.
Repository가 추상화되어 있으므로, 항상 같은 Interface로 데이터를 요청할 수 있다.
패턴을 사용하면 뭐가 좋은데?
데이터 로직과 비즈니스 로직을 분리할 수 있다. → 관심사의 분리
도메인에서는 일관된 인터페이스를 통해 데이터를 요청할 수 있다.
데이터 저장소의 데이터를 캡슐화할 수 있어 객체지향적인 프로그래밍에 더 적합하다.
단위 테스트를 통한 검증이 가능하며, 객체 간 결합도가 감소한다.
다양한 글들을 통해 Repository Pattern을 읽어보았다.
결국… 아래 참고에 써놨지만, 구글 디벨로퍼의 아키텍처만 쭉 잘 읽으면 뭐겠다 라고 알 순 있을 거 같다.
정리하자면, Repository가 나온 이유는 비즈니스 로직과 데이터 접근 과정을 최대한 분리해 서로간의 피해가 안가게끔 코드를 만들다 보니, 이를 해결하기 위해 Repository가 나왔으며, 패턴이 되었다. 패턴을 사용함으로써 더 이상 비즈니스 로직은 데이터가 어떻게, 어디서 호출되는지 알 필요가 없어졌으며, Repository를 통해 데이터를 요청할 수 있어졌다. 이렇게 됨으로써, 데이터를 캡슐화 할 수 있게 되었고, 객체 간 결합도가 감소해 단위 테스트가 쉬워졌다.
