Repository Pattern: apa itu, pola abstraksi data di iOS dan Android

Apa itu Repository Pattern dalam pengembangan mobile?

Repository Pattern — pola struktural yang mengisolasi logika bisnis dari akses langsung ke sumber data. Alih-alih Activity, UIViewController, atau ViewModel memanggil langsung Retrofit, URLSession, Room, atau CoreData, mereka merujuk ke Repository. Repository memutuskan dari mana mengambil data: dari jaringan, basis data, atau cache, dan mengembalikan hasil dalam format terpadu. Ini adalah implementasi prinsip tanggung jawab tunggal — UI tidak tahu bagaimana dan dari mana data diperoleh.

Komponen Repository mencakup antarmuka (protocol), implementasi, dan satu atau lebih DataSource. DataSource — kelas yang bekerja dengan satu sumber: RemoteDataSource memanggil API melalui klien HTTP, LocalDataSource membaca dan menulis ke basis data. Repository menerima DataSource melalui konstruktor (Dependency Injection) dan memilih sumber mana yang akan digunakan. Misalnya, saat meminta daftar pengguna, Repository pertama memeriksa cache, lalu basis data, lalu jaringan.

Keuntungan Repository Pattern: isolasi perubahan sumber data (perubahan API, migrasi DB) tidak memengaruhi lapisan UI; pengujian unit melalui penggantian Repository atau DataSource; caching transparan untuk UI; peralihan antara mode online dan offline tanpa mengubah logika layar. Komunitas Android merekomendasikan Repository sebagai lapisan wajib dalam Clean Architecture.

Repository Pattern di iOS dengan Swift: implementasi dan contoh

Implementasi iOS Repository dibangun di atas protokol Swift. Protokol Repository mendeklarasikan metode untuk mengambil dan menyimpan data. Implementasi aktual disuntikkan melalui inisialisasi — ini memungkinkan penggantian implementasi dalam pengujian dan preview SwiftUI. DataSource juga dideklarasikan dengan protokol: Protocol RemoteDataSource, Protocol LocalDataSource. ViewModel atau Interactor tidak tahu implementasi konkret — hanya tahu protokol 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 di iOS untuk Repository biasanya dikonfigurasi melalui pabrik atau kontainer DI (Swinject, Factory). Dalam pengujian, protokol UserRepository diganti dengan implementasi mock yang mengembalikan data yang telah ditentukan. Async-await membuat kode sinkron dan mudah dibaca tanpa closure dan delegate. Untuk reaktivitas Combine, metode Repository mengembalikan AnyPublisher alih-alih async throws.

Repository Pattern di Android dengan Kotlin: contoh dengan Flow

Implementasi Android Repository banyak menggunakan Kotlin Coroutines dan Flow untuk pekerjaan asinkron. Google merekomendasikan Repository dalam panduan resmi arsitektur Android (Android Architecture Components). Repository menerima RemoteDataSource (Retrofit) dan LocalDataSource (Room) melalui konstruktor, dan ViewModel berlangganan ke Flow dari Repository. Repository mengelola strategi data: pertama cache, lalu jaringan, atau selalu jaringan dengan menulis ke 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))
        }
    }
}

Pembungkus Result dalam contoh di atas adalah standar untuk Android: sealed class Result memberi tahu ViewModel tentang status pemuatan (Loading, Success, Error). ViewModel berlangganan melalui collect dan memperbarui StateFlow atau LiveData. Repository dengan Flow secara otomatis memberi tahu UI tentang perubahan di basis data — ini adalah perbedaan utama dari kueri satu kali di mana UI tidak tahu tentang perubahan tanpa penyegaran manual.

DataSource: Remote, Local, dan caching data

DataSource — kelas yang bertanggung jawab untuk bekerja dengan sumber data tertentu. RemoteDataSource menggunakan klien HTTP (URLSession, Retrofit, Ktor) untuk mengambil data dari API. LocalDataSource bekerja dengan penyimpanan lokal (CoreData, Realm, Room, UserDefaults, DataStore). Setiap DataSource memiliki tanggung jawab terbatas: RemoteDataSource hanya tahu format permintaan API, LocalDataSource — skema basis data. Repository menggabungkannya, mengimplementasikan strategi caching.

Strategi caching di Repository: Cache-First (pertama cache, lalu pemuatan latar belakang), Network-Only (hanya jaringan, untuk layar pembayaran), Network-First-With-Cache-Backup (pertama jaringan, jika error — cache). Pemilihan strategi tergantung pada skenario: daftar negara dapat di-cache untuk waktu lama, nilai tukar — 15 menit, saldo dompet — hanya dari jaringan. Repository mengimplementasikan strategi dan mengubahnya tanpa memodifikasi ViewModel atau UI.

Repository Pattern vs Service Layer: perbedaan dan pilihan

Repository dan Service — pola berbeda dengan fungsi yang tumpang tindih. Repository bertanggung jawab atas akses data dan caching, mengembalikan model data. Service (atau Interactor, Use Case) berisi logika bisnis: validasi, transformasi data, orkestrasi panggilan ke beberapa Repository. Service dapat menggabungkan UserRepository, OrderRepository, dan NotificationRepository untuk memproses pesanan. Repository tidak berisi logika bisnis — hanya CRUD dan caching.

Kapan memilih Repository — navigasi data dengan banyak sumber (API + DB + cache), arsitektur offline-first, kebutuhan caching dan peralihan transparan antar sumber. Repository wajib dalam Clean Architecture dan direkomendasikan oleh Google untuk aplikasi Android. Dalam arsitektur VIPER di iOS, peran Repository dilakukan oleh lapisan Interactor, yang berinteraksi dengan Manager atau Service untuk akses data.

Kapan Service cukup — aplikasi sederhana dengan satu sumber data, layar hanya-baca tanpa penulisan, proyek tanpa mode offline. Dalam kasus seperti itu, DataSource digunakan langsung oleh ViewModel atau Presenter, dan Repository menjadi lapisan yang berlebihan. Namun, menambahkan Repository di tahap awal tidak memerlukan biaya besar dan memudahkan penambahan caching dan pengujian di masa depan.