Repository Pattern: ما هو، نمط تجريد البيانات في iOS و Android

ما هو Repository Pattern في تطوير التطبيقات المحمولة؟

Repository Pattern هو نمط هيكلي يعزل منطق الأعمال عن الوصول المباشر إلى مصادر البيانات. بدلاً من أن تقوم Activity أو UIViewController أو ViewModel باستدعاء Retrofit أو URLSession أو Room أو CoreData مباشرة، فإنها تتواصل مع Repository. يقرر Repository من أين يحصل على البيانات — من الشبكة أو قاعدة البيانات أو التخزين المؤقت — ويعيد النتيجة بتنسيق موحد. هذا يطبق مبدأ المسؤولية الفردية — واجهة المستخدم لا تعرف كيف أو من أين تم الحصول على البيانات.

مكونات Repository تتضمن واجهة (بروتوكول)، وتنفيذ، وواحد أو أكثر من DataSources. DataSource هو فئة تعمل مع مصدر واحد: RemoteDataSource يستدعي API عبر عميل HTTP، LocalDataSource يقرأ ويكتب في قاعدة البيانات. يستقبل Repository DataSources عبر المنشئ (حقن التبعيات) ويقرر أي مصدر يستخدم. على سبيل المثال، عند طلب قائمة المستخدمين، يتحقق Repository أولاً من التخزين المؤقت، ثم قاعدة البيانات، ثم الشبكة.

فوائد Repository Pattern: عزل تغييرات مصادر البيانات (تغييرات API، ترحيل قاعدة البيانات) لا تؤثر على طبقة واجهة المستخدم؛ اختبار الوحدة عبر استبدال Repository أو DataSource؛ التخزين المؤقت شفاف لواجهة المستخدم؛ التبديل بين الأوضاع المتصلة وغير المتصلة دون تغيير منطق الشاشة. يوصي مجتمع Android باستخدام Repository كطبقة إلزامية في Clean Architecture.

Repository Pattern في iOS باستخدام Swift: التنفيذ والمثال

تنفيذ iOS لـ Repository مبني على بروتوكولات Swift. يعلن بروتوكول Repository عن طرق الحصول على البيانات وتخزينها. يتم حقن التنفيذ الفعلي عبر المُهيئ — هذا يسمح باستبدال التنفيذ في الاختبارات ومعاينات SwiftUI. يتم أيضًا تعريف DataSources كبروتوكولات: 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
    }
}

حقن التبعيات في iOS لـ Repository يتم تكوينه عادةً عبر مصنع أو حاوية DI (Swinject، Factory). في الاختبارات، يتم استبدال بروتوكول UserRepository بتنفيذ وهمي يعيد بيانات محددة مسبقًا. Async-await يجعل الكود متزامنًا وقابلاً للقراءة بدون closures و delegates. للتفاعل مع 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: فئة مختومة Result تُعلم ViewModel بحالة التحميل (تحميل، نجاح، خطأ). تشترك ViewModel عبر collect وتُحدّث StateFlow أو LiveData. Repository مع Flow يُعلم واجهة المستخدم تلقائيًا بالتغييرات في قاعدة البيانات — هذا فرق رئيسي عن الطلبات لمرة واحدة حيث لا تعرف واجهة المستخدم بالتغييرات دون تحديث يدوي.

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 أو واجهة المستخدم.

Repository Pattern مقابل 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 كافيًا — تطبيقات بسيطة بمصدر بيانات واحد، شاشات للقراءة فقط بدون كتابة، مشاريع بدون وضع عدم الاتصال. في هذه الحالات، يتم استخدام DataSource مباشرة بواسطة ViewModel أو Presenter، ويصبح Repository طبقة زائدة عن الحاجة. ومع ذلك، إضافة Repository في مرحلة مبكرة لا يتطلب جهدًا كبيرًا ويبسط إضافة التخزين المؤقت والاختبارات في المستقبل.