Repository

 

 

지난주 금요일부터 5일동안 강의를 듣고 자료를 찾아보고 직접 쳐봐도

repository패턴이 이해되지 않아 글을 써서 정리해보기로 했다.

인터페이스를 잘 모르니까 코드 동작원리가 전혀 와닿지 않았고 그나마 이해하고 있는 개념도 흔들렸다.

repository뿐만 아니라 보다 근본적인 개념도 같이 잡는 걸 목표로 작성을 시작한다.

 

---

 

 

 

Repository Pattern

데이터를 캡슐화하여 출처에 관계 없이 동일한 인터페이스로 데이터에 접근할 수 있도록 하는 패턴

 

출처에 관계 없이

내부에서 preference, room 등으로 저장한 cache data와 외부에서 api 등으로 끌어온 response data로 구분한다. ViewModel은 직접 Data에 접근해 데이터를 가져오는 것이 아니라 Repository에만 접근해 데이터를 가져오기 때문에 출처를 알 수 없고 알 필요가 없다.

 

인터페이스

과일빙수가게를 차렸다고 치자. 더우니까 빙수가 생각났다.

재료를 주문하고 받고 관리하는 건 Repository라는 분이 담당한다. 과일의 원산지가 cache한국이든 response외국이든 주방에서는 어느 나라 과일인지 알 필요 없이 들어온 재료만 받아서 주문대로 빙수를 만들어주면 된다. 

 

 

장점, 단점은 지겹게도 봤으니 생략한다. Repository와 ViewModel사이에 UseCase를 쓰는 방법도 있는데 지금은 알 필요 없으니 역시 생략한다. Repository Pattern은 ViewModel의 Data를 호출하는 부분에서 사용하므로 ViewModel에서부터 확인하면 된다. 그럼 ViewModel에서 Repository로 바로 갈 수 있겠지? 근데 아니다. 

 

 

 

Repository의 인터페이스는 UI Layer, 실제 데이터 구현체는 Data Layer에 존재한다. 

인터페이스와 구현체는 왜 다른 레이어에 있는가?

도움받은 블로거분도 나와 똑같은 의문을 제기했는데 나 역시 이해하지 못했다. 설명을 참고해 정리해본다.

 

1. 인터페이스가 UI Layer에 있는 이유 : UI Layer는 참조를 당할 뿐 다른 계층을 참조하지 않는다. ViewModel은 Repository를 참조해야하는데 UI Layer가 아닌 곳에 존재하면 상호참조가 발생하기 때문에 다른 모듈에 선언할 수 없다. 따라서 호출해야하는 계층에 같이 존재해야 하므로 UI Layer에 위치한다.
2. 구현체가 Data Layer에 있는 이유 : 구현체는 직접 데이터를 가져와서 관리해야하는데 UI Layer에서는 Data Layer에 있는 데이터를 가져올 수 없다. 따라서 Data Layer에 선언하여 UI Layer에 존재하는 인터페이스를 상속 받아서 사용하도록 Data Layer에 구현하는 것이다.

 

추가적으로 구현체는 cache와 Remote의 DataSource를 모두 사용할 수 있도록 보다 상위 패키지로 구현해야하고 인터페이스를 상속받으면서 두 가지 DataSource를 DI로 주입받아서 사용한다. 두 가지 DataSource 중, 원하는 데이터를 Return 시켜 ViewModel에서 사용할 수 있도록 한다.

 

다시 빙수가게로 돌아가자. View손님의 망고빙수 주문을 ViewModel이 받았다. 인터페이스로 Repository에게 망고를 요청한다. 인터페이스에 망고주문이 들어왔으니 구현체는 원산지에 상관없이 망고를 ViewModel에 전달한다. ViewModel은 망고빙수를 만들어 View에게 제공한다. 이러니 View는 Repository와 만날 일이 없는거다! 

 

 

 

 

 

 

 

 

 

도움받은 곳

https://heegs.tistory.com/90