Repository Pattern: ce este, modelul de abstractizare a datelor în iOS și Android

Ce este Repository Pattern în dezvoltarea mobilă?

Repository Pattern — un model structural care izolează logica de afaceri de accesul direct la sursele de date. În loc ca Activity, UIViewController sau ViewModel să apeleze direct Retrofit, URLSession, Room sau CoreData, acestea se adresează Repository-ului. Repository decide de unde să preia datele: din rețea, bază de date sau cache, și returnează rezultatul într-un format unic. Aceasta este o implementare a principiului responsabilității unice — UI nu știe cum și de unde au fost obținute datele.

Componentele Repository includ interfața (protocol), implementarea și unul sau mai multe DataSource-uri. DataSource — o clasă care lucrează cu o singură sursă: RemoteDataSource apelează API prin client HTTP, LocalDataSource citește și scrie în baza de date. Repository primește DataSource-urile prin constructor (Dependency Injection) și decide la ce sursă să se adreseze. De exemplu, la cererea listei de utilizatori, Repository verifică mai întâi cache-ul, apoi baza de date, apoi rețeaua.

Avantajele Repository Pattern: izolarea modificărilor surselor de date (schimbarea API, migrarea BD) nu afectează stratul UI; testarea unitară prin înlocuirea Repository sau DataSource; stocarea în cache transparentă pentru UI; comutarea între modurile online și offline fără modificarea logicii ecranului. Comunitatea Android recomandă Repository ca strat obligatoriu în Clean Architecture.

Repository Pattern în iOS cu Swift: implementare și exemplu

Implementarea iOS a Repository se bazează pe protocoale Swift. Protocolul Repository declară metodele de obținere și salvare a datelor. Implementarea reală este injectată prin inițializator — aceasta permite înlocuirea implementării în teste și în preview SwiftUI. DataSource-urile sunt de asemenea declarate prin protocoale: Protocol RemoteDataSource, Protocol LocalDataSource. ViewModel sau Interactor nu cunoaște implementarea concretă — cunoaște doar protocolul 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 în iOS pentru Repository se configurează de obicei printr-o fabrică sau container DI (Swinject, Factory). În teste, protocolul UserRepository este înlocuit cu o implementare mock care returnează date predefinite. Async-await face codul sincron și lizibil fără închideri și delegări. Pentru reactivitatea Combine, metodele Repository returnează AnyPublisher în loc de async throws.

Repository Pattern în Android cu Kotlin: exemplu cu Flow

Implementarea Android a Repository utilizează pe scară largă Kotlin Coroutines și Flow pentru lucrul asincron. Google recomandă Repository în ghidul oficial de arhitectură Android (Android Architecture Components). Repository primește RemoteDataSource (Retrofit) și LocalDataSource (Room) prin constructor, iar ViewModel se abonează la Flow din Repository. Repository gestionează strategia datelor: mai întâi cache, apoi rețea sau întotdeauna rețea cu scriere în cache.

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

Înfășurătoarea Result în exemplul de mai sus este standardă pentru Android: sealed class Result informează ViewModel despre starea încărcării (Loading, Success, Error). ViewModel se abonează prin collect și actualizează StateFlow sau LiveData. Repository cu Flow notifică automat UI despre modificările din baza de date — aceasta este diferența cheie față de cererile unice, unde UI nu află despre modificări fără reîmprospătare manuală.

DataSource: Remote, Local și stocarea în cache a datelor

DataSource — clase responsabile pentru lucrul cu o anumită sursă de date. RemoteDataSource folosește un client HTTP (URLSession, Retrofit, Ktor) pentru a obține date din API. LocalDataSource lucrează cu stocarea locală (CoreData, Realm, Room, UserDefaults, DataStore). Fiecare DataSource are o responsabilitate restrânsă: RemoteDataSource știe doar formatul cererii API, LocalDataSource — schema bazei de date. Repository le combină, implementând strategia de stocare în cache.

Strategii de stocare în cache în Repository: Cache-First (mai întâi cache, apoi încărcare în fundal), Network-Only (doar rețea, pentru ecrane de plată), Network-First-With-Cache-Backup (mai întâi rețea, la eroare — cache). Alegerea strategiei depinde de scenariu: lista țărilor poate fi stocată în cache pentru mult timp, cursurile valutare — 15 minute, soldul portofelului — doar din rețea. Repository implementează strategia și o modifică fără a schimba ViewModel sau UI.

Repository Pattern vs Service Layer: diferențe și alegere

Repository și Service — modele diferite cu funcții care se suprapun. Repository răspunde pentru accesul la date și stocarea lor în cache, returnând modele de date. Service (sau Interactor, Use Case) conține logica de afaceri: validare, transformare a datelor, orchestrarea apelurilor mai multor Repository-uri. Service poate combina UserRepository, OrderRepository și NotificationRepository pentru procesarea unei comenzi. Repository nu conține logică de afaceri — doar CRUD și stocare în cache.

Când să alegeți Repository — navigare prin date cu surse multiple (API + BD + cache), arhitectură offline-first, necesitatea stocării în cache și comutării transparente între surse. Repository este obligatoriu în Clean Architecture și recomandat de Google pentru aplicațiile Android. În arhitectura VIPER pe iOS, rolul Repository este îndeplinit de stratul Interactor, care interacționează cu Manager sau Service pentru accesul la date.

Când este suficient Service — aplicații simple cu o singură sursă de date, ecrane doar pentru citire fără scriere, proiecte fără mod offline. În astfel de cazuri, DataSource este utilizat direct de ViewModel sau Presenter, iar Repository devine un strat redundant. Cu toate acestea, adăugarea Repository într-un stadiu incipient nu necesită costuri mari și simplifică adăugarea stocării în cache și a testelor în viitor.