https://sungbin.land/repository-datasource-business-logic-자세히-알아보기-e1a07701b972
https://developer.android.com/topic/architecture/data-layer?hl=ko
DataSource
-
DataSource = 데이터를 불러오는 출처
-
DataSource = 데이터를 로드하고 저장하는 데 사용되는 추상화된 인터페이스
-
DataSource = 데이터 액세스를 위한 실제 구현을 캡슐화 하는 인터페이스
-
각 Data source class들은 반드시 한 종류의 data의 source만을 포함해야 한다.(= 데이터의 출처는 단 한 곳) -> network로 쓰든, local DB로 쓰든 하나로만 해야 된다는 의미.
Repository
- Data Layer는 여러 개의 Data source들을 포함할 수 있는 Repository들로 구성된다.
- 앱에서 처리하는 다양한 유형의 데이터별로 Repository Class를 만들어야 한다.
ex) 영화 관련 데이터를 처리할 땐 moviesRepository, 결제 관련 데이터를 처리할 땐 PaymentsRepository를 만들어서 처리한다.
- Repository classes are responsible for the following tasks:
- 앱의 나머지 부분에 Data를 exporting
- 데이터의 변경사항들을 한 곳에 집중시킨다.(=중앙 관리)
- 여러 Data sources들 간의 conflicts를 Resolving
- 앱의 나머지 부분들로부터 data의 sources들을 추상화한다.
- Business-logic을 포함한다.
- 각 Data source class들은 반드시 한 종류의 data의 source만을 포함해야 한다.
- Data source class는 데이터 작업을 위한 애플리케이션과 시스템 간의 가교 역할을 수행
- 계층 구조의 다른 Layer들은 Data source에 직접 접근하면 안된다.
반드시 Data layer의 진입점은 Repository class여야 한다.
Repository class를 진입점으로 사용하면 아키텍처의 다양한 Layer들을 독립적으로 확장시킬 수 있기 때문 ! - 이 Layer에 expose된 data들은 변경이 불가능해야된다.(immutable)
그래야 값을 일관되지 않은 상태로 만들 위험이 있는 다른 클래스에 의한 조작을 방지할 수 있기 때문.
// Repository에서 상황에 맞게 DataSource를 사용하면 된다.
class ExampleRepository(
private val exampleRemoteDataSource: ExampleRemoteDataSource, // network
private val exampleLocalDataSource: ExampleLocalDataSource // database
) { /* ... */ }-
Repository는 DataSource에서 데이터를 가져오고 캐싱하며, 데이터에 대한 비즈니스 로직을 처리하여 앱에서 일관된 데이터 액세스를 제공한다.
-
즉, Repository는 App과 DataSource 간의 중재자 역할을 수행하여 DataSource의 구체적인 세부 내용을 숨기고 App에 논리적인 데이터 액세스 인터페이스를 제공한다.
-
Repository는 서로 다른 DataSource들을 결합하고, DataSource 간의 potential한 Conflicts들을 해결하여 정기적으로 또는 사용자 입력 이벤트에 따라 Source를 업데이트한다.
-
App에서 사용하는 Repository마다 정보 소스가 다를 수 있는데,
예를 들어 LoginRepository Class는 캐시를 정보 소스로 사용하고, PaymentsRepository Class는 Network DataSource를 정보 소스로 사용할 수 있다. -
오프라인 우선 지원을 제공하려면 데이터베이스와 같은 로컬 데이터 소스를 정보 소스로 사용하는 것이 좋다.
Naming conventions
- Repository Class의 이름은 담당하는 Data의 이름에 따라 지정됨.
type of data + Repository.
For example: NewsRepository, MoviesRepository, or PaymentsRepository.
- Data source class의 이름은 담당하는 Data와 사용하는 Source의 이름에 따라 지정됨.
type of data + type of source + DataSource.
이때, "type of data"는 구현이 변경될 수 있으므로 일반적인 Remote, Local을 사용한다.
For example: NewsRemoteDataSource or NewsLocalDataSource.
단, 구현 세부정보에 따라 DataSource의 이름을 지정하면 안된다.
(예: UserSharedPreferencesDataSource).
해당 데이터 소스를 사용하는 저장소가 데이터 저장 방법을 알 수 없기 때문.
이 규칙을 따르면 데이터 소스의 구현을 변경(예: SharedPreferences에서 DataStore로 이전)하면서도 해당 소스를 호출하는 레이어에 영향을 주지 않을 수 있다.
Multiple levels of repositories
복잡한 비즈니스 요구사항을 포함할 경우, 한 Repository가 다른 Repository에 종속될 수도 있다.
관련된 데이터가 여러 DataSource의 집계이거나, 책임이 다른 Repository class에 캡슐화되어야 하기 때문일 수 있음.
- 예를 들어, 사용자 인증 데이터를 처리하는 저장소인 UserRepository는 요구사항을 충족하기 위해 LoginRepository 및 RegistrationRepository와 같은 다른 Repository에 종속될 수 있음.
Business Logic
App에서 일어나는 어떠한 일련의 작업 프로세스를 칭한다.
-
Business Logic = 애플리케이션의 핵심 비즈니스 규칙과 프로세스를 구현하는 부분.
UI와 DataSource(예: 데이터베이스, 네트워크) 사이에서 데이터를 처리하고 조작하는 역할. -
Business Logic은 사용자와 상호작용하며, 앱의 기능을 실현하고 애플리케이션의 비즈니스 요구사항을 충족시키는 역할을 한다.
Business Logic은 주로 애플리케이션의 핵심 로직을 담당하며, 애플리케이션의 안정성, 성능, 확장성을 보장하기 위해 모듈화되고 재사용 가능한 형태로 개발된다.
이를 위해 Android에서는 ViewModel, Repository 패턴, Retrofit 등의 도구와 라이브러리를 사용하며, MVVM (Model-View-ViewModel), Clean Architecture 등의 아키텍처 패턴과 함께 사용되어 구현됨.
배달앱에서의 Business Logic
-
사용자 인증:
사용자의 로그인 및 회원가입 처리
로그인 상태 유지: 사용자의 로그인 상태를 유지하고, 로그인이 필요한 기능에 대한 접근 관리 -
위치 기반 서비스:
사용자의 현재 위치 정보를 수집하고, 주변 가게를 찾거나 주문 배송 위치를 설정하는 등의 작업을 수행 -
지도 및 경로 안내: 사용자에게 지도를 표시하고, 주문 배송 경로를 안내하는 기능을 구현
-
주문 관리:
주문 목록 표시: 사용자의 주문 내역을 가져와 화면에 표시
주문 상태 업데이트: 주문의 진행 상태를 업데이트하고, 사용자에게 주문 상태를 알립니다.
결제 처리: 주문된 상품의 가격을 결제하고, 결제 정보를 처리 -
푸시 알림:
주문 상태 변경 알림: 주문 상태가 변경될 때 사용자에게 푸시 알림을 보내어 알림
프로모션 알림: 할인 이벤트나 새로운 가게 오픈 등의 프로모션 정보를 푸시 알림으로 전달 -
UI 상호작용:
사용자 입력 처리: 사용자의 주문, 검색, 필터링 등의 입력을 받아 처리
화면 전환 및 내비게이션: 앱 내에서 다양한 화면 간의 전환을 처리하고, 필요한 데이터 전달과 상태 관리를 담당 -
서버 API와의 통신: 주문 정보를 서버로 전송하거나, 주문 상태 업데이트를 서버에 요청하는 등의 네트워크 통신 처리
