倉庫模式及其在Swift 專案中的應用詳解

2023-01-28 18:01:12

正文

在現代 Swift 專案中，很流行一種模式叫做倉庫模式，英文是 Repository Pattern。這個模式主要用於構建資料層程式碼。按照一般的 App 層級劃分，一般從上到下劃分為 UI 層，業務層，資料層，那麼倉庫模式的應用位置可以參考下圖：

可以看到倉庫應用在資料層，業務層通過介面來存取倉庫。

不使用倉庫模式時的程式碼

為了研究為什麼要使用倉庫模式，我們先看看不使用倉庫模式時我們是怎麼寫程式碼的。一般開啟一個介面，會傳送網路請求來獲取這個介面所需的資料，這時會在 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)
        }
    }
}

這種寫法在小專案中是沒有問題的，但是在稍具規模的專案中，就會對專案的擴充套件性，維護性，團隊合作，開發效率有比較高的要求，這時候就更應該根據科學的軟體設計原則來設計更好的架構。

上面的程式碼在稍具規模的專案中會有以下的缺點：

資料存取程式碼寫在了 ViewController 中，無法測試
ViewController 會過於臃腫，難以維護
如果資料存取方式修改了，需要修改 ViewController 中的程式碼

稍具規模的專案一般會採用 MVVM 等架構，於是以上的程式碼會寫在 ViewModel 中，來避免 ViewController 太過臃腫，但是還是會有無法測試和修改資料存取方式時改動比較大的問題。

使用倉庫有什麼好處？

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

倉庫模式提供了資料層的抽象，可以讓你的業務程式碼只依賴一個簡單的抽象介面就可以工作。這使得程式碼鬆耦合，業務程式碼不需要知道資料的具體獲取和儲存細節。

倉庫模式讓程式碼可以測試，對於網路請求和資料庫讀寫的部分，可以實現一個提供測試資料的倉庫範例，這樣就可以編寫相應的測試程式碼。

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

設計倉庫介面

按照依賴倒轉原則，資料存取層作為架構中的一個整體，上層物件在呼叫資料存取層時應該依賴介面，而不依賴於實現，這樣資料存取層的邏輯就可以靈活的變更、替換，比如在網路請求和本地資料之間切換，在不同的網路請求協定之間切換等。

所以設計倉庫模式應該先定義介面，定義介面有兩種方式，一種是根據具體的資料定義特定的倉庫介面，例如對於一個新聞列表的介面：

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

或者是根據不同的業務資料的存取邏輯其實大同小異，可以設計統一的泛型介面：

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
}

實現倉庫介面

我們一般會根據資料的存放方式來定義不同的倉庫實現，比如對於網路請求的資料，定義一種倉庫的實現，對於本地資料庫中存放的資料定義一種倉庫的實現，也可以定義一種假資料倉儲來編寫測試程式碼。

比如對於網路請求的資料，可以定義一個如下的倉庫實現：

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

對於本地資料，可以設計一個如下的倉庫實現：

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

為了編寫測試程式碼，可以提供一個假資料的倉庫實現：

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

如果需要從介面請求到資料後放入本地資料庫快取，然後從本地資料庫中讀取資料渲染在介面上，也可以用一個倉庫搞定。

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

選擇用哪個倉庫實現

在現代 App 專案中，一般會用 MVVM 等架構來組織程式碼。這裡以 MVVM 為例，ViewModel 會依賴倉庫介面來存取資料。

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

為了提高程式碼的維護性和擴充套件性，最好使用依賴注入的方式來給 ViewModel 注入 Repository 的依賴，這樣可以方便得替換倉庫的實現而不用修改 ViewModel 的程式碼。

可以在建立 ViewModel 時建立對應的倉庫物件，也可以使用依賴注入容器。

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

處理資料來源的變更

當遇到需要變更資料來源的時候，例如本地資料庫從 CoreData 切換到 SQLite 或 Realm。或者更換了網路庫，從 NSURLSession 換成 Alamofire，這些情況倉庫模式就能發揮它的優勢。無需修改業務方程式碼，只需要替換成一種新的倉庫實現即可。

還有另一種情況，就是對於同一個業務，後端協定變更了。如果使用了倉庫模式，也可以很方便的進行程式碼調整。

通常，業務層會有一個業務模型，比如對於使用者的資訊，在業務層定義了一套模型：

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

原本通過介面返回的 json 字串:

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

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

如果沒有用倉庫模式，業務方直接依賴具體的資料模型，如果介面結構調整了，那麼所有的業務呼叫方的程式碼都要調整。

使用了倉庫模式，業務方依賴於倉庫，倉庫可以在獲取到資料結構後將它轉為業務方需要的資料模型，這樣無論後端協定怎麼變更，都可以僅在資料層增加一種新的倉庫實現，不需要改動業務方程式碼。這遵守了開放-封閉程式設計原則。

總結

在稍具規模的專案中使用倉庫模式，可以讓程式碼抽象度更高，耦合度更低，方便擴充套件和維護，可以編寫測試程式碼，在大型專案中，可以方便的實現資料來源和資料結構的切換。倉庫模式也將資料儲存的細節和程式的其它部分分離開，使得職責更清晰。

倉庫模式也有一些缺點：為了實現這一模式需要編寫更多的程式碼，增加了程式碼複雜性。需要編寫對映程式碼來講資料對映為業務模型。如果是小型的專案就不需要使用倉庫模式了。

參考資料

以上就是倉庫模式及其在Swift 專案中的應用詳解的詳細內容，更多關於Swift 專案倉庫模式的資料請關注it145.com其它相關文章！