Repository Pattern: その概要、iOSとAndroidにおけるデータ抽象化パターン

モバイル開発におけるRepository Patternとは？

Repository Patternは、ビジネスロジックをデータソースへの直接アクセスから隔離する構造パターンです。Activity、UIViewController、ViewModelが直接Retrofit、URLSession、Room、CoreDataを呼び出す代わりに、Repositoryと通信します。Repositoryはデータをネットワーク、データベース、キャッシュのどこから取得するかを決定し、統一された形式で結果を返します。これは単一責任の原則を実装しています — UIはデータがどのように、どこから取得されたかを知りません。

Repositoryのコンポーネントには、インターフェース（プロトコル）、実装、1つ以上のDataSourceが含まれます。DataSourceは単一のソースを扱うクラスです: RemoteDataSourceはHTTPクライアントを介してAPIを呼び出し、LocalDataSourceはデータベースの読み書きを行います。Repositoryはコンストラクタ（依存性注入）を介してDataSourceを受け取り、使用するソースを決定します。たとえば、ユーザー一覧を要求する場合、Repositoryは最初にキャッシュ、次にデータベース、次にネットワークを確認します。

Repository Patternの利点: データソースの変更（API変更、DB移行）がUIレイヤーに影響しないこと、RepositoryまたはDataSourceの置き換えによる単体テスト、UIに対して透過的なキャッシュ、画面ロジックを変更せずにオンラインとオフラインモードを切り替え可能。AndroidコミュニティはClean ArchitectureにおいてRepositoryを必須レイヤーとして推奨しています。

Swiftを使用したiOSでのRepository Pattern: 実装と例

iOSの実装におけるRepositoryはSwiftのプロトコルに基づいています。Repositoryプロトコルはデータの取得と保存のメソッドを宣言します。実際の実装はイニシャライザを介して注入されます — これにより、テストやSwiftUIプレビューでの実装の置き換えが可能になります。DataSourceもプロトコルとして宣言されます: Protocol RemoteDataSource、Protocol LocalDataSource。ViewModelやInteractorは特定の実装を知りません — Repositoryプロトコルのみを知っています。

protocol UserRepository {
    func getUsers() async throws -> [User]
}

protocol UserRemoteDataSource {
    func fetchUsers() async throws -> [User]
}

protocol UserLocalDataSource {
    func getCachedUsers() throws -> [User]
    func saveUsers(_: [User]) throws
}

final class UserRepositoryImpl: UserRepository {
    private let remote: UserRemoteDataSource
    private let local: UserLocalDataSource

    init(remote: UserRemoteDataSource, local: UserLocalDataSource) {
        self.remote = remote
        self.local = local
    }

    func getUsers() async throws -> [User] {
        if let cached = try? local.getCachedUsers() {
            return cached
        }
        let users = try await remote.fetchUsers()
        try local.saveUsers(users)
        return users
    }
}

依存性注入はiOSのRepositoryでは通常、ファクトリまたはDIコンテナ（Swinject、Factory）を介して構成されます。テストでは、UserRepositoryプロトコルは事前定義されたデータを返すモック実装に置き換えられます。Async-awaitにより、クロージャやデリゲートなしで同期的で読みやすいコードになります。Combineのリアクティビティには、Repositoryのメソッドはasync throwsの代わりにAnyPublisherを返します。

Kotlinを使用したAndroidでのRepository Pattern: Flowの例

Androidの実装におけるRepositoryは、非同期操作にKotlin CoroutinesとFlowを広く利用しています。Googleは公式のAndroidアーキテクチャガイド（Android Architecture Components）でRepositoryを推奨しています。Repositoryはコンストラクタを介してRemoteDataSource（Retrofit）とLocalDataSource（Room）を受け取り、ViewModelはRepositoryからのFlowを購読します。Repositoryはデータ戦略を管理します: キャッシュファースト、ネットワークファースト、または常にネットワークでキャッシュへの書き込み。

interface UserRepository {
    fun getUsers(): Flow<Result<List<User>>>
}

interface UserRemoteDataSource {
    suspend fun fetchUsers(): List<User>
}

interface UserLocalDataSource {
    fun getCachedUsers(): Flow<List<User>>
    suspend fun saveUsers(users: List<User>)
}

class UserRepositoryImpl(
    private val remote: UserRemoteDataSource,
    private val local: UserLocalDataSource
) : UserRepository {

    override fun getUsers(): Flow<Result<List<User>>> = flow {
        emit(Result.Loading)
        local.getCachedUsers().collect { cached ->
            if (cached.isNotEmpty()) {
                emit(Result.Success(cached))
            }
        }
        try {
            val users = remote.fetchUsers()
            local.saveUsers(users)
            emit(Result.Success(users))
        } catch (e: Exception) {
            emit(Result.Error(e))
        }
    }
}

Resultラッパーは上記の例ではAndroidの標準です: シールドクラスResultがViewModelにローディング状態（Loading、Success、Error）を通知します。ViewModelはcollectを介して購読し、StateFlowまたはLiveDataを更新します。Flowを使用したRepositoryはデータベースの変更をUIに自動的に通知します — これは手動更新なしではUIが変更を認識できない単発リクエストとの重要な違いです。

DataSource: Remote、Local、データキャッシング

DataSource — 特定のデータソースを扱うクラスです。RemoteDataSourceはHTTPクライアント（URLSession、Retrofit、Ktor）を使用してAPIからデータを取得します。LocalDataSourceはローカルストレージ（CoreData、Realm、Room、UserDefaults、DataStore）を扱います。各DataSourceは狭い責任を持ちます: RemoteDataSourceはAPIリクエスト形式のみを知り、LocalDataSourceはデータベーススキーマのみを知ります。Repositoryはこれらを組み合わせ、キャッシュ戦略を実装します。

Repositoryのキャッシュ戦略: Cache-First（最初にキャッシュ、次にバックグラウンドロード）、Network-Only（ネットワークのみ、支払い画面用）、Network-First-With-Cache-Backup（最初にネットワーク、エラー時にキャッシュにフォールバック）。戦略の選択はシナリオに依存します: 国のリストは長期間キャッシュ可能、為替レートは15分間、ウォレット残高はネットワークのみ。Repositoryは戦略を実装し、ViewModelやUIを変更せずにそれを変更します。

Repository Pattern vs Service Layer: 違いと選択

RepositoryとServiceは機能が重複する異なるパターンです。Repositoryはデータアクセスとキャッシュを担当し、データモデルを返します。Service（またはInteractor、Use Case）はビジネスロジックを含みます: 検証、データ変換、複数のRepository呼び出しのオーケストレーション。Serviceは注文を処理するためにUserRepository、OrderRepository、NotificationRepositoryを組み合わせることができます。Repositoryはビジネスロジックを含まず、CRUDとキャッシュのみを担当します。

Repositoryを選ぶべき時 — 複数のソース（API + DB + キャッシュ）を用いたデータナビゲーション、オフラインファーストアーキテクチャ、キャッシュと透過的なソース切り替えの必要性。Clean ArchitectureではRepositoryが必須であり、GoogleはAndroidアプリケーションに推奨しています。iOSのVIPERアーキテクチャでは、Repositoryの役割はInteractorレイヤーが担い、データアクセスのためにManagerやServiceと連携します。

Serviceで十分な時 — 単一のデータソースを持つシンプルなアプリケーション、書き込みのない読み取り専用画面、オフラインモードのないプロジェクト。そのような場合、DataSourceはViewModelまたはPresenterによって直接使用され、Repositoryは不要なレイヤーになります。ただし、早期にRepositoryを追加しても大きな労力は必要なく、将来的なキャッシュ追加やテストが容易になります。