正文

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

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

不使用倉庫模式時(shí)的代碼

為了研究為什么要使用倉庫模式，我們先看看不使用倉庫模式時(shí)我們是怎么寫代碼的。一般打開一個(gè)界面，會(huì)發(fā)送網(wǎng)絡(luò)請(qǐng)求來獲取這個(gè)界面所需的數(shù)據(jù)，這時(shí)會(huì)在 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)
        }
    }
}

這種寫法在小項(xiàng)目中是沒有問題的，但是在稍具規(guī)模的項(xiàng)目中，就會(huì)對(duì)項(xiàng)目的擴(kuò)展性，維護(hù)性，團(tuán)隊(duì)合作，開發(fā)效率有比較高的要求，這時(shí)候就更應(yīng)該根據(jù)科學(xué)的軟件設(shè)計(jì)原則來設(shè)計(jì)更好的架構(gòu)。

上面的代碼在稍具規(guī)模的項(xiàng)目中會(huì)有以下的缺點(diǎn)：

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

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

使用倉庫有什么好處？

總的來說，就是能提供高層次的抽象，從而獲得因?yàn)槌橄髱淼囊幌盗泻锰帯?/p>

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

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

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

設(shè)計(jì)倉庫接口

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

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

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

或者是根據(jù)不同的業(yè)務(wù)數(shù)據(jù)的訪問邏輯其實(shí)大同小異，可以設(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
}

實(shí)現(xiàn)倉庫接口

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

比如對(duì)于網(wǎng)絡(luò)請(qǐng)求的數(shù)據(jù)，可以定義一個(gè)如下的倉庫實(shí)現(xiàn)：

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

對(duì)于本地?cái)?shù)據(jù)，可以設(shè)計(jì)一個(gè)如下的倉庫實(shí)現(xiàn)：

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

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

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

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

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
    }
}

選擇用哪個(gè)倉庫實(shí)現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

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

可以直接通過解析 JSON 然后構(gòu)造出 DomainUser 對(duì)象，但是突然某一天后端說要技術(shù)調(diào)整，遷移到新的接口，新接口返回的結(jié)構(gòu)和以前不一樣了。

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

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

總結(jié)

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

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

參考資料

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

以上就是倉庫模式及其在Swift 項(xiàng)目中的應(yīng)用詳解的詳細(xì)內(nèi)容，更多關(guān)于Swift 項(xiàng)目倉庫模式的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論