Repository Pattern: vad är det, mönster för dataabstraktion i iOS och Android

Vad är Repository Pattern inom mobilutveckling?

Repository Pattern — ett strukturellt mönster som isolerar affärslogik från direkt åtkomst till datakällor. Istället för att Activity, UIViewController eller ViewModel direkt anropar Retrofit, URLSession, Room eller CoreData, vänder de sig till Repository. Repository bestämmer var data ska hämtas: från nätverket, databasen eller cachen, och returnerar resultatet i ett enhetligt format. Detta är en implementering av principen om enskilt ansvar — UI vet inte hur och var data har hämtats.

Repository-komponenter inkluderar gränssnitt (protocol), implementering och en eller flera DataSources. DataSource — en klass som arbetar med en källa: RemoteDataSource anropar API via HTTP-klient, LocalDataSource läser och skriver till databasen. Repository tar emot DataSources via konstruktorn (Dependency Injection) och väljer vilken källa att använda. Vid en begäran om användarlista kontrollerar Repository först cachen, sedan databasen, därefter nätverket.

Fördelar med Repository Pattern: isolering av ändringar i datakällor (API-ändring, DB-migrering) påverkar inte UI-lagret; enhetstestning genom att ersätta Repository eller DataSource; cachning transparent för UI; växling mellan online- och offlineläge utan att ändra skärmlogik. Android-communityt rekommenderar Repository som ett obligatoriskt lager i Clean Architecture.

Repository Pattern i iOS med Swift: implementering och exempel

iOS-implementering av Repository bygger på Swift-protokoll. Repository-protokollet deklarerar metoder för att hämta och spara data. Den faktiska implementeringen injiceras via initieraren — detta möjliggör byte av implementering i tester och SwiftUI-förhandsvisningar. DataSources deklareras också med protokoll: Protocol RemoteDataSource, Protocol LocalDataSource. ViewModel eller Interactor känner inte till den konkreta implementeringen — bara Repository-protokollet.

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 i iOS för Repository konfigureras vanligtvis via en fabrik eller DI-container (Swinject, Factory). I tester ersätts UserRepository-protokollet med en mock-implementering som returnerar fördefinierade data. Async-await gör koden synkron och läsbar utan closures och delegater. För Combine-reaktivitet returnerar Repository-metoder AnyPublisher istället för async throws.

Repository Pattern i Android med Kotlin: exempel med Flow

Android-implementering av Repository använder flitigt Kotlin Coroutines och Flow för asynkront arbete. Google rekommenderar Repository i den officiella Android-arkitekturguiden (Android Architecture Components). Repository tar emot RemoteDataSource (Retrofit) och LocalDataSource (Room) via konstruktorn, och ViewModel prenumererar på Flow från Repository. Repository hanterar datastrategi: först cache, sedan nätverk, eller alltid nätverk med skrivning till 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))
        }
    }
}

Result-omslag i exemplet ovan är standard för Android: sealed class Result informerar ViewModel om laddningsstatus (Loading, Success, Error). ViewModel prenumererar via collect och uppdaterar StateFlow eller LiveData. Repository med Flow meddelar automatiskt UI om ändringar i databasen — detta är den viktigaste skillnaden från engångsfrågor där UI inte får reda på ändringar utan manuell uppdatering.

DataSource: Remote, Local och cachelagring av data

DataSource — klasser som ansvarar för att arbeta med en specifik datakälla. RemoteDataSource använder HTTP-klient (URLSession, Retrofit, Ktor) för att hämta data från API. LocalDataSource arbetar med lokal lagring (CoreData, Realm, Room, UserDefaults, DataStore). Varje DataSource har ett snävt ansvar: RemoteDataSource känner bara till API-begäranformatet, LocalDataSource — databasschemat. Repository kombinerar dem och implementerar en cachelagringsstrategi.

Cachelagringsstrategier i Repository: Cache-First (först cache, sedan bakgrundsladdning), Network-Only (endast nätverk, för betalningsskärmar), Network-First-With-Cache-Backup (först nätverk, vid fel — cache). Valet av strategi beror på scenario: landslista kan cachas länge, valutakurser — 15 minuter, plånbokssaldo — endast från nätverket. Repository implementerar strategin och ändrar den utan att ändra ViewModel eller UI.

Repository Pattern vs Service Layer: skillnader och val

Repository och Service — olika mönster med överlappande funktioner. Repository ansvarar för dataåtkomst och cachning och returnerar datamodeller. Service (eller Interactor, Use Case) innehåller affärslogik: validering, datatransformering, orkestrering av anrop till flera Repository. Service kan kombinera UserRepository, OrderRepository och NotificationRepository för att behandla en beställning. Repository innehåller ingen affärslogik — endast CRUD och cachning.

När välja Repository — datanavigering med flera källor (API + DB + cache), offline-first-arkitektur, behov av cachning och transparent växling mellan källor. Repository är obligatoriskt i Clean Architecture och rekommenderas av Google för Android-applikationer. I VIPER-arkitektur på iOS utförs Repository-rollen av Interactor-lagret, som interagerar med Manager eller Service för dataåtkomst.

När räcker Service — enkla applikationer med en datakälla, skrivskyddade skärmar utan skrivning, projekt utan offlineläge. I sådana fall används DataSource direkt av ViewModel eller Presenter, och Repository blir ett överflödigt lager. Att lägga till Repository i ett tidigt skede kräver dock inte stora kostnader och underlättar framtida tillägg av cachning och tester.