서론

나름 repository 패턴을 잘 적용했다고 생각했는데

다만 데이터 레이어에서 레포지터리와 데이터소스 그리고 데이터소스를 구현하고 있는 Remote 영역의 관심사가 잘못 만들어져 있습니다.

라는 피드백을 받고 정리하는 시간을 갖기로 했다.

본론

Repository 패턴이란?

안드로이드 아키텍처는 3가지 계층으로 나누어진다.
UI Layer / Domain Layer / Data Layer
이 중 Data 계층에서 이 repository 패턴이 활용된다.

더 자세한 구조이다.
위의 그림처럼 Repository 패턴은 데이터를 어디서 가져오는지 감출 수 있게 한다.
ui 계층과 domain 계층에서는 repository를 통해 갖게 된 데이터가 SQLite에서 온 것인지, WebService에서 온 것인지 알 수 없다.

왜 이걸 써요?

그렇다면 이 Repository 패턴은 왜 써야할까?

이 repository 패턴은 인터페이스로 Data 계층을 추상화한다.
그렇게 때문에 Data Source가 다양하더라도 호출에 관한 일관성을 가질 수 있고 새로운 Data의 추가도 쉽다.
또, Ui 계층 + Domain 계층과 Data 계층 간의 결합도가 줄어든다.
마지막으로 테스트가 용이해진다!

어떻게 써요?

이렇게 글로만 쓰면 이해가 잘 안된다.
코드를 보자.

OrderRepository

interface OrderRepository {

    fun order(...)

    fun cancelOrder(...)

    fun getOrderHistory(...)
}

장바구니 앱에서 주문하기 기능을 구현한다고 했을 때,
1. 주문하기(주문 데이터 저장)
2. 취소하기(주문 데이터 수정)
3. 주문내역 조회(주문 데이터 조회)
의 기능이 필요하다.

그리고 각 데이터에 맞게 이 Repository를 구현하는 RepositoryImpl들이 만들어진다.

OrderRepositoryImpl

OrderRemoteRepositoryImpl

class OrderRemoteRepositoryImpl(
    private val remoteDataSource: OrderRemoteDataSource
) : OrderRepository {

    override fun order(...) {...}

    override fun cancelOrder(...) {...}

    override fun getOrderHistory(...) {...}
}

OrderLocalRepositoryImpl

class OrderLocalRepositoryImpl(
    private val localDataSource: OrderLocalDataSource
) : OrderRepository {

    override fun order(...) {...}

    override fun cancelOrder(...) {...}

    override fun getOrderHistory(...) {...}
}

이와같이 일관된 함수로 여러 DataSource에서 원하는 작업을 할 수 있다.

그리고 이 DataSource도 Repository와 같이 추상화하여 사용할 수 있다!