Repository Pattern: qué es, el patrón de abstracción de datos en iOS y Android

¿Qué es el Repository Pattern en el desarrollo móvil?

Repository Pattern es un patrón estructural que aísla la lógica de negocio del acceso directo a las fuentes de datos. En lugar de que una Activity, UIViewController o ViewModel llame directamente a Retrofit, URLSession, Room o CoreData, se comunican con el Repository. El Repository decide de dónde obtener los datos — de la red, la base de datos o la caché — y devuelve el resultado en un formato unificado. Esto implementa el principio de responsabilidad única: la UI no sabe cómo ni de dónde se obtuvieron los datos.

Los componentes del Repository incluyen una interfaz (protocolo), una implementación y uno o más DataSources. Un DataSource es una clase que trabaja con una sola fuente: RemoteDataSource llama a la API mediante un cliente HTTP, LocalDataSource lee y escribe en la base de datos. El Repository recibe los DataSources a través del constructor (Inyección de Dependencias) y decide qué fuente utilizar. Por ejemplo, al solicitar una lista de usuarios, el Repository primero verifica la caché, luego la base de datos y luego la red.

Ventajas del Repository Pattern: el aislamiento de los cambios en las fuentes de datos (cambios de API, migraciones de BD) no afecta a la capa de UI; pruebas unitarias mediante la sustitución del Repository o DataSource; el almacenamiento en caché es transparente para la UI; cambio entre modos online y offline sin modificar la lógica de la pantalla. La comunidad de Android recomienda Repository como capa obligatoria en Clean Architecture.

Repository Pattern en iOS con Swift: implementación y ejemplo

La implementación en iOS del Repository se basa en protocolos de Swift. El protocolo Repository declara métodos para obtener y almacenar datos. La implementación real se inyecta a través del inicializador — esto permite reemplazar la implementación en pruebas y previsualizaciones de SwiftUI. Los DataSources también se declaran como protocolos: Protocol RemoteDataSource, Protocol LocalDataSource. La ViewModel o Interactor no conoce una implementación específica — solo el protocolo 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
    }
}

Inyección de Dependencias en iOS para Repository se configura típicamente a través de una fábrica o contenedor DI (Swinject, Factory). En las pruebas, el protocolo UserRepository se reemplaza con una implementación mock que devuelve datos predefinidos. Async-await hace que el código sea síncrono y legible sin closures ni delegados. Para la reactividad con Combine, los métodos del Repository devuelven AnyPublisher en lugar de async throws.

Repository Pattern en Android con Kotlin: ejemplo con Flow

La implementación en Android del Repository utiliza ampliamente Kotlin Coroutines y Flow para operaciones asíncronas. Google recomienda Repository en la guía oficial de arquitectura de Android (Android Architecture Components). El Repository acepta RemoteDataSource (Retrofit) y LocalDataSource (Room) a través del constructor, y la ViewModel se suscribe a un Flow del Repository. El Repository gestiona la estrategia de datos: caché primero, red primero, o siempre red con escritura en caché.

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))
        }
    }
}

Wrapper Result en el ejemplo anterior es estándar para Android: una clase sellada Result informa a la ViewModel sobre el estado de carga (Loading, Success, Error). La ViewModel se suscribe mediante collect y actualiza StateFlow o LiveData. Repository con Flow notifica automáticamente a la UI sobre cambios en la base de datos — esta es una diferencia clave con las solicitudes únicas donde la UI no sabe de los cambios sin actualización manual.

DataSource: Remote, Local y almacenamiento en caché

DataSource — clases responsables de trabajar con una fuente de datos específica. RemoteDataSource utiliza un cliente HTTP (URLSession, Retrofit, Ktor) para obtener datos de la API. LocalDataSource trabaja con almacenamiento local (CoreData, Realm, Room, UserDefaults, DataStore). Cada DataSource tiene una responsabilidad limitada: RemoteDataSource solo conoce el formato de la solicitud API, LocalDataSource — el esquema de la base de datos. El Repository los combina, implementando una estrategia de almacenamiento en caché.

Estrategias de almacenamiento en caché en Repository: Cache-First (caché primero, luego carga en segundo plano), Network-Only (solo red, para pantallas de pago), Network-First-With-Cache-Backup (red primero, fallback a caché en caso de error). La elección de la estrategia depende del escenario: una lista de países puede almacenarse en caché por mucho tiempo, los tipos de cambio — por 15 minutos, el saldo de la billetera — solo desde la red. El Repository implementa la estrategia y la cambia sin modificar la ViewModel o la UI.

Repository Pattern vs Service Layer: diferencias y elección

Repository y Service son patrones diferentes con funciones superpuestas. Repository es responsable del acceso a datos y su almacenamiento en caché, devolviendo modelos de datos. Service (o Interactor, Use Case) contiene lógica de negocio: validación, transformación de datos, orquestación de llamadas a múltiples Repositories. Service puede combinar UserRepository, OrderRepository y NotificationRepository para procesar un pedido. Repository no contiene lógica de negocio — solo CRUD y almacenamiento en caché.

Cuándo elegir Repository — navegación de datos con múltiples fuentes (API + BD + caché), arquitectura offline-first, necesidad de almacenamiento en caché y cambio transparente de fuentes. Repository es obligatorio en Clean Architecture y recomendado por Google para aplicaciones Android. En la arquitectura VIPER en iOS, el rol de Repository lo desempeña la capa Interactor, que interactúa con Manager o Service para el acceso a datos.

Cuándo Service es suficiente — aplicaciones simples con una sola fuente de datos, pantallas de solo lectura sin escritura, proyectos sin modo offline. En tales casos, DataSource es utilizado directamente por la ViewModel o Presenter, y Repository se convierte en una capa innecesaria. Sin embargo, agregar Repository en una etapa temprana no requiere un esfuerzo significativo y simplifica la adición de almacenamiento en caché y pruebas en el futuro.