Repository Pattern: что это, паттерн абстракции данных в iOS и Android

Что такое Repository Pattern в мобильной разработке?

Repository Pattern — структурный паттерн, изолирующий бизнес-логику от прямого доступа к источникам данных. Вместо того чтобы Activity, UIViewController или ViewModel напрямую вызывали Retrofit, URLSession, Room или CoreData, они обращаются к Repository. Repository решает, откуда брать данные: из сети, базы или кэша, и возвращает результат в едином формате. Это реализация принципа единственной ответственности — UI не знает, как и откуда получены данные.

Компоненты Repository включают интерфейс (protocol), реализацию и один или несколько DataSource. DataSource — класс, работающий с одним источником: RemoteDataSource вызывает API через HTTP-клиент, LocalDataSource читает и пишет в базу данных. Repository принимает DataSource через конструктор (Dependency Injection) и выбирает, к какому источнику обратиться. Например, при запросе списка пользователей Repository сначала проверяет кэш, потом базу, затем сеть.

Преимущества Repository Pattern: изоляция изменений источников данных (смена API, миграция БД) не затрагивает UI-слой; unit-тестирование через подмену Repository или DataSource; кэширование прозрачно для UI; переключение между онлайн и офлайн режимами без изменения логики экрана. Сообщество Android рекомендует Repository как обязательный слой в Clean Architecture.

Repository Pattern в iOS на Swift: реализация и пример

iOS-реализация Repository строится на протоколах Swift. Протокол Repository объявляет методы для получения и сохранения данных. Реальная реализация внедряется через инициализатор — это позволяет подменять реализацию в тестах и preview 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
    }
}

Dependency Injection в iOS для Repository обычно настраивается через фабрику или DI-контейнер (Swinject, Factory). В тестах протокол UserRepository заменяется mock-реализацией, возвращающей предопределённые данные. Async-await делает код синхронным и читаемым без замыканий и делегатов. Для Combine-реактивности методы Repository возвращают AnyPublisher вместо async throws.

Repository Pattern в Android на Kotlin: пример с Flow

Android-реализация Repository широко использует Kotlin Coroutines и Flow для асинхронной работы. Google рекомендует Repository в официальном гайде по архитектуре Android (Android Architecture Components). Repository принимает RemoteDataSource (Retrofit) и LocalDataSource (Room) через конструктор, а ViewModel подписывается на Flow из Repository. 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: sealed class Result сообщает ViewModel о состоянии загрузки (Loading, Success, Error). ViewModel подписывается через collect и обновляет StateFlow или LiveData. Repository с Flow автоматически уведомляет 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 + БД + кэш), offline-first архитектура, необходимость кэширования и прозрачного переключения источников. Repository обязателен в Clean Architecture и рекомендуется Google для Android-приложений. В архитектуре VIPER на iOS роль Repository выполняет Interactor-слой, взаимодействующий с Manager или Service для доступа к данным.

Когда достаточно Service — простые приложения с одним источником данных, read-only экраны без записи, проекты без офлайн-режима. В таких случаях DataSource используется напрямую ViewModel или Presenter, а Repository становится избыточным слоем. Однако добавление Repository на раннем этапе не требует больших затрат и упрощает добавление кэширования и тестов в будущем.