正文

在現(xiàn)代 Swift 項目中，很流行一種模式叫做倉庫模式，英文是 Repository Pattern。這個模式主要用于構建數(shù)據(jù)層代碼。按照一般的 App 層級劃分，一般從上到下劃分為 UI 層，業(yè)務層，數(shù)據(jù)層，那么倉庫模式的應用位置可以參考下圖：

可以看到倉庫應用在數(shù)據(jù)層，業(yè)務層通過接口來訪問倉庫。

不使用倉庫模式時的代碼

為了研究為什么要使用倉庫模式，我們先看看不使用倉庫模式時我們是怎么寫代碼的。一般打開一個界面，會發(fā)送網(wǎng)絡請求來獲取這個界面所需的數(shù)據(jù)，這時會在 ViewController 寫類似下面的代碼：

func viewDidLoad() {
    super.viewDidLoad()
    requestData()
}
func requestData() {
    API.request(xxxId: 12345) { result in
        switch result {
        case .success(let model):
            handle(model)
            DispatchQueue.main.async {
                render(model)
            }
        case .failure(let error):
            print(error.localizedString)
        }
    }
}

這種寫法在小項目中是沒有問題的，但是在稍具規(guī)模的項目中，就會對項目的擴展性，維護性，團隊合作，開發(fā)效率有比較高的要求，這時候就更應該根據(jù)科學的軟件設計原則來設計更好的架構。

上面的代碼在稍具規(guī)模的項目中會有以下的缺點：

• 數(shù)據(jù)訪問代碼寫在了 ViewController 中，無法測試
• ViewController 會過于臃腫，難以維護
• 如果數(shù)據(jù)訪問方式修改了，需要修改 ViewController 中的代碼

稍具規(guī)模的項目一般會采用 MVVM 等架構，于是以上的代碼會寫在 ViewModel 中，來避免 ViewController 太過臃腫，但是還是會有無法測試和修改數(shù)據(jù)訪問方式時改動比較大的問題。

使用倉庫有什么好處？

總的來說，就是能提供高層次的抽象，從而獲得因為抽象帶來的一系列好處。

倉庫模式提供了數(shù)據(jù)層的抽象，可以讓你的業(yè)務代碼只依賴一個簡單的抽象接口就可以工作。這使得代碼松耦合，業(yè)務代碼不需要知道數(shù)據(jù)的具體獲取和存儲細節(jié)。

倉庫模式讓代碼可以測試，對于網(wǎng)絡請求和數(shù)據(jù)庫讀寫的部分，可以實現(xiàn)一個提供測試數(shù)據(jù)的倉庫實例，這樣就可以編寫相應的測試代碼。

下面就來看一看怎樣使用倉庫模式。

設計倉庫接口

按照依賴倒轉原則，數(shù)據(jù)訪問層作為架構中的一個整體，上層對象在調用數(shù)據(jù)訪問層時應該依賴接口，而不依賴于實現(xiàn)，這樣數(shù)據(jù)訪問層的邏輯就可以靈活的變更、替換，比如在網(wǎng)絡請求和本地數(shù)據(jù)之間切換，在不同的網(wǎng)絡請求協(xié)議之間切換等。

所以設計倉庫模式應該先定義接口，定義接口有兩種方式，一種是根據(jù)具體的數(shù)據(jù)定義特定的倉庫接口，例如對于一個新聞列表的接口：

protocol NewsListRepository {
    func readNewsList() async throws -> [News] 
}

或者是根據(jù)不同的業(yè)務數(shù)據(jù)的訪問邏輯其實大同小異，可以設計統(tǒng)一的泛型接口：

protocol Repository {
    associatedtype T
    func query(with predicate: NSPredicate?, sortDescriptors: [NSSortDescriptor]?) async throws -> [T]
    func save(entity: T) async throws
    func delete(entity: T) async throws
}

實現(xiàn)倉庫接口

我們一般會根據(jù)數(shù)據(jù)的存放方式來定義不同的倉庫實現(xiàn)，比如對于網(wǎng)絡請求的數(shù)據(jù)，定義一種倉庫的實現(xiàn)，對于本地數(shù)據(jù)庫中存放的數(shù)據(jù)定義一種倉庫的實現(xiàn)，也可以定義一種假數(shù)據(jù)倉庫來編寫測試代碼。

比如對于網(wǎng)絡請求的數(shù)據(jù)，可以定義一個如下的倉庫實現(xiàn)：

class DefaultNewsListRepository: NewsListRepository {
    let remoteDataSource: NewsListRemoteAPI
    init(remoteDataSource: NewsListRemoteDataSource) {
        self.remoteDataSource = remoteDataSource
    }
    func readNewsList() async throws -> [News] {
        return remoteDataSource.requestNewsList();
    }
}

對于本地數(shù)據(jù)，可以設計一個如下的倉庫實現(xiàn)：

class DatabaseNewsListRepository: NewsListRepository {
    let newsListDataStore: NewsListDataStore
    init(newsListRemoteAPI: NewsListRemoteAPI) {
        self.newsListRemoteAPI = newsListRemoteAPI
    }
    func readNewsList() async throws -> [News] {
        return newsListRemoteAPI.requestNewsList();
    }
}

為了編寫測試代碼，可以提供一個假數(shù)據(jù)的倉庫實現(xiàn)：

class FakeNewsListRepository: NewsListRepository {
    func readNewsList() async throws -> [News] {
        return [
            News(),
            News(),
            News()
        ]
    }
}

如果需要從接口請求到數(shù)據(jù)后放入本地數(shù)據(jù)庫緩存，然后從本地數(shù)據(jù)庫中讀取數(shù)據(jù)渲染在界面上，也可以用一個倉庫搞定。

class DefaultNewsListRepository: NewsListRepository {
    let newsListRemoteAPI: NewsListRemoteAPI
    let newsListDataStore: NewsListDataStore
    init(newsListRemoteAPI: NewsListRemoteAPI, newsListDataStore: NewsListDataStore) {
        self.newsListRemoteAPI = newsListRemoteAPI
        self.newsListDataStore = newsListDataStore
    }
    func readNewsList() async throws -> [News] {
        var newsList = newsListDataStore.readNewsList()
        if newsList.count == 0 {
            let news = newsListRemoteAPI.requestNewsList()
            newsListDataStore.save(newsList)
            newsList = news
        }   
        return newsList
    }
}

選擇用哪個倉庫實現(xiàn)

在現(xiàn)代 App 項目中，一般會用 MVVM 等架構來組織代碼。這里以 MVVM 為例，ViewModel 會依賴倉庫接口來存取數(shù)據(jù)。

class NewsListViewModel: ViewModel {
    let newsListRepository: NewsListRepository
    init(newsListRepository: NewsListRepositoy) {
        self.newsListRepository = newsListRepository
    }
}

為了提高代碼的維護性和擴展性，最好使用依賴注入的方式來給 ViewModel 注入 Repository 的依賴，這樣可以方便得替換倉庫的實現(xiàn)而不用修改 ViewModel 的代碼。

可以在創(chuàng)建 ViewModel 時創(chuàng)建對應的倉庫對象，也可以使用依賴注入容器。

init(newsListRepository: NewsListRepository = DIContainer.shared.resolve(NewsListRepository.self)) {
    self.newsListRepository = newsListRepository
}

處理數(shù)據(jù)源的變更

當遇到需要變更數(shù)據(jù)源的時候，例如本地數(shù)據(jù)庫從 CoreData 切換到 SQLite 或 Realm?；蛘吒鼡Q了網(wǎng)絡庫，從 NSURLSession 換成 Alamofire，這些情況倉庫模式就能發(fā)揮它的優(yōu)勢。無需修改業(yè)務方代碼，只需要替換成一種新的倉庫實現(xiàn)即可。

還有另一種情況，就是對于同一個業(yè)務，后端協(xié)議變更了。如果使用了倉庫模式，也可以很方便的進行代碼調整。

通常，業(yè)務層會有一個業(yè)務模型，比如對于用戶的信息，在業(yè)務層定義了一套模型：

struct DomainUser {
    let name: String
    let age: Int
    let nickname: String
}

原本通過接口返回的 json 字符串:

{ 
    "name": "zhangsan",
    "age": 20,
    "nickname": "xiaozhang"
}

可以直接通過解析 JSON 然后構造出 DomainUser 對象，但是突然某一天后端說要技術調整，遷移到新的接口，新接口返回的結構和以前不一樣了。

如果沒有用倉庫模式，業(yè)務方直接依賴具體的數(shù)據(jù)模型，如果接口結構調整了，那么所有的業(yè)務調用方的代碼都要調整。

使用了倉庫模式，業(yè)務方依賴于倉庫，倉庫可以在獲取到數(shù)據(jù)結構后將它轉為業(yè)務方需要的數(shù)據(jù)模型，這樣無論后端協(xié)議怎么變更，都可以僅在數(shù)據(jù)層增加一種新的倉庫實現(xiàn)，不需要改動業(yè)務方代碼。這遵守了開放-封閉程序設計原則。

總結

在稍具規(guī)模的項目中使用倉庫模式，可以讓代碼抽象度更高，耦合度更低，方便擴展和維護，可以編寫測試代碼，在大型項目中，可以方便的實現(xiàn)數(shù)據(jù)源和數(shù)據(jù)結構的切換。倉庫模式也將數(shù)據(jù)存儲的細節(jié)和程序的其它部分分離開，使得職責更清晰。

倉庫模式也有一些缺點：為了實現(xiàn)這一模式需要編寫更多的代碼，增加了代碼復雜性。需要編寫映射代碼來講數(shù)據(jù)映射為業(yè)務模型。如果是小型的項目就不需要使用倉庫模式了。

參考資料

• iOS: Repository pattern in Swift
• Repository Pattern in Swift
• github.com/kudoleh/iOS…

以上就是倉庫模式及其在Swift 項目中的應用詳解的詳細內容，更多關于Swift 項目倉庫模式的資料請關注腳本之家其它相關文章！

最新評論