Repository Pattern이 뭔데요?
Repository Pattern은 공식문서에 따르면 데이터 레이어를 나머지 부분에서 분리하는 디자인 패턴입니다.
왜 쓰는데요?
데이터 레이어는 UI와는 별도로 앱의 데이터와 비즈니스 로직을 처리하는 앱 부분을 나타내며 앱의 나머지 부분에서 이 데이터에 액세스할 수 있습니다. 이렇게 되면...
- Data Layer와 Presentation Layer 간의 결합도가 줄어듭니다.
- Presentation Layer에서 Data Layer에 직접 접근하지 않으므로, 새로운 Data의 추가가 쉽습니다.
- Presentation Layer에서는 Repository에 데이터 요청만 하면 되므로, 일관된 인터페이스로 데이터를 요청할 수 있습니다.
Repository는 Data Source(예: 영구 모델, 웹 서비스, 캐시) 간의 충돌을 해결하고 이 데이터의 변경사항을 중앙 집중화할 수 있습니다. 오른쪽 다이어그램은 Activity와 같은 앱 구성요소가 저장소를 통해 데이터 소스와 상호작용하는 모습을 나타냅니다.
어떻게 쓰는데요?
Repository 인터페이스와 구현체를 작성합니다.
- Repository 인터페이스: 앱의 ViewModel이나 UseCase에서 직접 사용하는 인터페이스로, 구체적인 데이터 소스가 어떻게 구성되는지 알 필요 없이, 인증 관련 작업에 접근할 수 있는 API를 제공합니다.
- 구현체(implement) 클래스: Repository의 구현체로, RemoteDataSource와 LocalDataSource의 데이터 소스 객체를 주입받아 데이터를 가져옵니다.
그리고 뷰모델 생성자의 매개변수로 Repository구현체를 넘겨주고 Repository의 원하는 함수를 작성합니다.
저희 프로젝트에서는 UseCase 생성자의 매개변수로 넘겨주고 사용하였습니다.
데이터 소스의 분리
ViewModel이나 앱의 다른 부분은 실제 데이터가 네트워크에서 가져오는지 로컬 데이터베이스에서 가져오는지 알 필요가 없으므로, Repository 클래스를 사용해 ViewModel 클래스와 분리하면 앱 구조를 깔끔하게 유지할 수 있습니다.
장점
1. 데이터 액세스와 비즈니스 로직의 분리: Repository는 데이터 액세스 인터페이스를 제공하여 비즈니스 로직 계층과 데이터 액세스 계층을 분리합니다. 이를 통해 비즈니스 로직은 데이터 소스의 세부 사항을 몰라도 데이터를 쉽게 요청하고 저장할 수 있습니다.
2. 테스트 용이성: Repository가 인터페이스로 추상화되어 있어 테스트하기 쉽습니다. 가짜 또는 메모리 기반 데이터 소스로 Repository를 구현하여 테스트 환경에서 유연하게 사용할 수 있습니다.
3. 확장성: Repository는 데이터 액세스 계층을 캡슐화하여 다른 데이터 소스(예: 네트워크, 로컬 데이터베이스)로의 전환이나 새로운 데이터 소스 추가가 용이합니다.
4. 데이터 소스 관리 및 오프라인 지원: Repository는 네트워크와 로컬 캐시를 포함한 여러 데이터 소스를 관리하고, 오프라인 상태에서도 최신 데이터에 접근할 수 있도록 합니다.
5. 단일 정보 소스 역할: 앱 데이터의 일관성을 유지하고, 네트워크와 캐시를 통합하여 항상 최신 데이터로 앱이 작동하도록 보장합니다.
결론 모듈식이고 테스트 가능한 구조가 되어 코드 유지보수가 용이하고 유연한 데이터 관리를 구현할 수 있습니다.
