https://developer.android.com/codelabs/basic-android-kotlin-training-repository-pattern#3
https://heegs.tistory.com/90
https://vagabond95.me/posts/android-repository-pattern/
https://devvkkid.tistory.com/196
- Repository Pattern
- Repository Pattern은 App의 나머지 부분으로부터 Data Layer를 격리하는 디자인 패턴.
- Data Layer는 App의 Data 및 비즈니스 로직을 처리하는 UI와는 별개인 App의 일부를 나타내며 App의 나머지 부분이 이 data에 액세스할 수 있도록 일관된 API를 노출한다.
- UI가 사용자에게 정보를 제공하는 동안 Data Layer는 networking code, Room databases, error handling 및 data를 읽거나 조작하는 모든 코드가 포함됨.
- data Sources에 액세스하는 logic을 캡슐화하는 Repository class를 구현하는 Pattern
- Repository는 안드로이드 어플리케이션 내부의 일종의 API 역할을 수행함.
(UI Layer와 Data Sources 사이에 Repository들이 위치)
( 클라이언트(=ViewModel) <--통신-- API(=Repository) --통신--> 서버(=data source) )
Repository는 data Sources(예: persistent model, Web services 및 Caches) 간의 충돌을 해결하고 이 data에 대한 변경 사항을 중앙 집중화할 수 있음.
아래 다이어그램은 Activity와 같은 App Component가 Repository를 통해 data sources와 상호 작용할 수 있는 방법을 보여줌.
- 로직
( View(=Activity,Fragment) -> viewModel -> Repository -> DataSource(Remote, Local Data)
( Presentation Layer -> (Domain Layer) -> Data Layer )
- Repository Class는 Data Layer를 제외한 App의 나머지 부분으로부터 data sources를 분리하고 App의 나머지 부분에게 data Access를 위한 API를 제공.
- code separation 및 Architecture에 권장됨.
- Repository Class를 사용하면 code가 ViewModel Class와 분리됨.
-> viewModel(Presentation(= UI) Layer)에서 직접 Data Layer에 있는 DataSource에 Access해 data를 참조하는 것이 아니라 viewModel에서 Repository에 접근하고 Repository가 data Layer에 있는 DataSource에 접근해 Room이나 Retrofit 등과 같이 Local, Remote Data에 접근해 Data를 가져오는 것이다.
- 보통 클린아키텍쳐에서 domain Layer의 UseCase에서 Repository를 호출한다.
(단, Repository의 구현부인 RepositoryImpl은 Data Layer에 존재한다.)
(UseCase는 Repository를 통해 비즈니스 로직을 구현하는 부분) - ViewModel에서는 구체적인 디테일에 신경 쓸 필요 없이 단순히 UseCase에게 받은 리턴Data를 UI에 expose하기만 하면 된다. 따라서, Repository의 구현부(Data Layer)에 의존하지 않고 Presentation(UI) Layer를 구성할 수 있다.
이렇게 로직으로 수행될 수 있도록 하기 위해 Repository Pattern을 사용하는 것.
(Repository로 인해 Presentation Layer와 Data Layer의 coupling을 약하게 함)
-
Advantages of using a repository
- Repository Module은 data operations을 처리하고 여러 backend를 사용할 수 있게 해줌.
- 일반적인 실제 App에서 Repository는 Network에서 Data를 가져올지 또는 Local Database에 캐시된 Data를 사용할지를 결정하기 위한 logic을 구현함.
- Repository를 사용하면 view models와 같은 calling code에 영향을 주지 않고 다른 persistence library로 migration하는 것과 같은 implementation details를 교환할 수 있다.
- Code를 모듈화하고 테스트 가능하게 만드는 데 도움.
Repository는 App의 Data의 특정 부분에 대한 신뢰할 수 있는 single source 역할을 해야 한다.
네트워크 리소스 및 오프라인 캐시와 같은 여러 data sources로 작업할 때 Repository는 App의 Data가 가능한 한 정확하고 최신 상태인지 확인하여 App이 오프라인일 때도 best possible experience를 제공한다.
- Caching
캐시는 앱에서 사용하는 Data Storage를 의미.
예를 들어, 사용자의 인터넷 연결이 interrupt된 경우에 대비하여 네트워크의 Data를 일시적으로 save할 때 쓰인다.
- 네트워크를 더 이상 사용할 수 없더라도 App은 여전히 캐시된 Data를 사용할 수 있다.
- 캐시는 더 이상 화면에 표시되지 않는 Activity에 대한 임시 Data를 저장하거나 App 실행 사이에 Data를 유지하는 데에도 유용.
캐시는 특정 작업에 따라 더 간단하거나 더 복잡한 다양한 형태를 취할 수 있음.
다음 표는 Android에서 네트워크 캐싱을 구현하는 여러 가지 방법이다.
| Caching Technique | 용도 |
|---|---|
| Retrofit은 Android를 위한 type-safe REST client를 구현하는 데 사용되는 networking library. 모든 network 통신 결과의 copy를 로컬에 저장하도록 Retrofit을 구성할 수 있음. | simple requests와 responses 그리고 빈번한 network 호출, small dataset에 적합한 solution |
| DataStore는 key-value Pairs를 저장하는데 유용 | App Setting과 같은 key-value에 유용한 solution. 큰 structured data에는 적합하지 않음 |
| SQLite를 통해 abstraction layer를 제공하는 SQLite object-mapping library인 Room을 사용해 Data를 캐시할 수 있음. | 디바이스의 파일 시스템에 구조화된 데이터를 저장하는 가장 좋은 방법은 로컬 SQLite 데이터베이스에 있기 때문에 복잡한 구조화된 쿼리 가능 데이터(structured queryable data)에 권장되는 Solution |
