Repository Pattern: มันคืออะไร รูปแบบการสรุปข้อมูลใน iOS และ Android

Repository Pattern ในการพัฒนาแอปมือถือคืออะไร?

Repository Pattern เป็นรูปแบบเชิงโครงสร้างที่แยกตรรกะทางธุรกิจออกจากการเข้าถึงแหล่งข้อมูลโดยตรง แทนที่ Activity, UIViewController หรือ ViewModel จะเรียก Retrofit, URLSession, Room หรือ CoreData โดยตรง พวกมันจะสื่อสารกับ Repository Repository ตัดสินใจว่าจะรับข้อมูลจากที่ไหน — จากเครือข่าย ฐานข้อมูล หรือแคช — และส่งคืนผลลัพธ์ในรูปแบบที่รวมเป็นหนึ่งเดียว ซึ่งใช้หลักการความรับผิดชอบเดียว — UI ไม่ทราบว่าข้อมูลถูกได้รับมาอย่างไรหรือจากที่ไหน

ส่วนประกอบของ Repository ประกอบด้วยอินเทอร์เฟซ (โปรโตคอล) การนำไปใช้ และ DataSource หนึ่งรายการขึ้นไป DataSource คือคลาสที่ทำงานกับแหล่งเดียว: RemoteDataSource เรียก API ผ่าน HTTP ไคลเอ็นต์, LocalDataSource อ่านและเขียนในฐานข้อมูล Repository รับ DataSources ผ่านคอนสตรักเตอร์ (Dependency Injection) และตัดสินใจว่าจะใช้แหล่งใด ตัวอย่างเช่น เมื่อขอรายชื่อผู้ใช้ Repository จะตรวจสอบแคชก่อน จากนั้นฐานข้อมูล จากนั้นเครือข่าย

ข้อดี ของ Repository Pattern: การแยกการเปลี่ยนแปลงแหล่งข้อมูล (การเปลี่ยนแปลง API, การย้าย DB) ไม่กระทบต่อชั้น UI; การทดสอบหน่วยผ่านการแทนที่ Repository หรือ DataSource; การแคชโปร่งใสต่อ UI; การสลับระหว่างโหมดออนไลน์และออฟไลน์โดยไม่เปลี่ยนแปลงตรรกะของหน้าจอ ชุมชน 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
    }
}

Dependency Injection ใน iOS สำหรับ Repository โดยทั่วไปกำหนดค่าผ่านโรงงานหรือคอนเทนเนอร์ DI (Swinject, Factory) ในการทดสอบ โปรโตคอล UserRepository จะถูกแทนที่ด้วยการนำไปใช้จำลองที่ส่งคืนข้อมูลที่กำหนดไว้ล่วงหน้า Async-awatt ทำให้โค้ดทำงานแบบซิงโครนัสและอ่านง่ายโดยไม่ต้องใช้ 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: คลาส sealed Result แจ้ง ViewModel เกี่ยวกับสถานะการโหลด (กำลังโหลด สำเร็จ ข้อผิดพลาด) ViewModel สมัครสมาชิกผ่าน collect และอัปเดต StateFlow หรือ LiveData Repository กับ Flow แจ้ง UI โดยอัตโนมัติเกี่ยวกับการเปลี่ยนแปลงในฐานข้อมูล — นี่คือข้อแตกต่างหลักจากคำขอครั้งเดียวที่ UI ไม่ทราบเกี่ยวกับการเปลี่ยนแปลงหากไม่มีการรีเฟรชด้วยตนเอง

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 หรือ UI

Repository Pattern vs Service Layer: ความแตกต่างและการเลือก

Repository และ Service เป็นรูปแบบที่แตกต่างกันซึ่งมีฟังก์ชันทับซ้อน Repository รับผิดชอบการเข้าถึงข้อมูลและการแคช ส่งคืนโมเดลข้อมูล Service (หรือ Interactor, Use Case) มีตรรกะทางธุรกิจ: การตรวจสอบความถูกต้อง การแปลงข้อมูล การประสานงานการเรียก Repository หลายครั้ง Service สามารถรวม UserRepository, OrderRepository และ NotificationRepository เพื่อดำเนินการตามคำสั่งซื้อ Repository ไม่มีตรรกะทางธุรกิจ — มีเพียง CRUD และการแคช

เมื่อใดควรเลือก Repository — การนำทางข้อมูลกับหลายแหล่ง (API + DB + แคช), สถาปัตยกรรมแบบออฟไลน์ก่อน, ความจำเป็นในการแคชและการสลับแหล่งที่โปร่งใส Repository เป็นสิ่งบังคับใน Clean Architecture และ Google แนะนำสำหรับแอปพลิเคชัน Android ในสถาปัตยกรรม VIPER บน iOS บทบาทของ Repository ดำเนินการโดยชั้น Interactor ซึ่งโต้ตอบกับ Manager หรือ Service สำหรับการเข้าถึงข้อมูล

เมื่อใด Service เพียงพอ — แอปพลิเคชันง่าย ๆ ที่มีแหล่งข้อมูลเดียว หน้าจอแบบอ่านอย่างเดียวโดยไม่มีการเขียน โปรเจกต์ที่ไม่มีโหมดออฟไลน์ ในกรณีเช่นนี้ DataSource ถูกใช้โดยตรงโดย ViewModel หรือ Presenter และ Repository กลายเป็นชั้นที่เกินความจำเป็น อย่างไรก็ตาม การเพิ่ม Repository ในระยะแรกไม่ต้องใช้ความพยายามมากและทำให้การเพิ่มแคชและการทดสอบในอนาคตง่ายขึ้น