原文：https://msdn.microsoft.com/en-us/library/ff649690.aspx

Context:

在很多應用程序中，業(yè)務邏輯從數(shù)據(jù)存儲(例如數(shù)據(jù)庫，web)中訪問數(shù)據(jù)，直接訪問數(shù)據(jù)可能會造成這樣的后果：

1.重復編碼

2.編程錯誤的可能性增大

3.弱類型的業(yè)務數(shù)據(jù)//強弱類型的區(qū)別就是類型安全檢查，內(nèi)存檢查，動態(tài) 靜態(tài)類型檢查

4.難以集中管理數(shù)據(jù)相關的策略（如緩存）

5.難以讓業(yè)務邏輯隔離外部依賴去進行測試

解決方法：

? ? ? ? Use a repository to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model（使用倉庫將檢索數(shù)據(jù)和實體模型的映射與作用于實體的的業(yè)務邏輯分離）.業(yè)務邏輯應該與包含此數(shù)據(jù)的數(shù)據(jù)層實現(xiàn)無關，比如說，數(shù)據(jù)層可以是數(shù)據(jù)庫，一個網(wǎng)絡服務等。

? ? ? ? 程序中的repository應該是在數(shù)據(jù)層和業(yè)務邏輯層中間，它從數(shù)據(jù)層查詢數(shù)據(jù)，將數(shù)據(jù)從數(shù)據(jù)源映射到業(yè)務實體，并將業(yè)務實體的更改保留到數(shù)據(jù)源。存儲庫將業(yè)務邏輯與與底層數(shù)據(jù)源或Web服務的交互分離。數(shù)據(jù)層和業(yè)務層之間的分離有三個好處：

1.集中了數(shù)據(jù)邏輯或web服務訪問邏輯

2.It provides a substitution point for the unit tests.（為單元測試提供了一個替代點）

3.提供了一種靈活的架構，可以隨著程序的整體設計的發(fā)展而進行調(diào)整

repository有兩種方法去查詢業(yè)務實體：

? 1.它可以向客戶端的業(yè)務邏輯提交查詢對象

? 2.他可以使用指定業(yè)務標準的方法

在第二種情況下，repository代表客戶端進行查詢。repository返回一組滿足查詢的實體集合。下圖顯示了repository與客戶端和數(shù)據(jù)源的交互：

客戶端為了實現(xiàn)持久性存儲給repository提交新的或更改過的實體，在復雜的情況下，客戶端業(yè)務邏輯可以使用工作單元模式，這種模式展示了如何封裝彼此一致或具有相關依賴關系的幾個相關操作。已經(jīng)封裝好的項會被發(fā)送到repository去進行更新或刪除，本指南不包括工作單元模式的示例。

repository是不同的域(domain)中數(shù)據(jù)和操作之間的橋梁。

一個常見的例子就是將一個弱類型數(shù)據(jù)的域（數(shù)據(jù)庫，SharePoint list）映射到一個強數(shù)據(jù)類型的域中（域中實體模型）。

一個典型的例子就是數(shù)據(jù)庫使用IDbCommand對象執(zhí)行查詢并返回一個IDataReader的對象.

另一個例子就是SharePoint,使用SPQuery對象去返回SPListItem的集合。repository向數(shù)據(jù)源發(fā)出正確的查詢，查詢結束后將結果集映射到外部的業(yè)務實體。repository通常使用Data Mapper(數(shù)據(jù)映射)模式在表示層之間進行轉換。它移除了客戶端對指定技術的依賴關系。比如說，如果客戶端調(diào)用目錄倉庫去獲取產(chǎn)品數(shù)據(jù)，它只需要調(diào)用倉庫的商品目錄接口（catalog repository interface）。再比方說，客戶端不需要知道商品信息是通過SQL查詢語句從數(shù)據(jù)庫中查詢的還是通過協(xié)作應用標記語言（Collaborative Application Markup Language (CAML)）從Sharepoint列表查詢的。隔離這些類型的依賴性提供了一種實現(xiàn)的靈活性。

實施細節(jié)：

這部分論述了SharePoint列表庫和Web服務庫的實現(xiàn)策略.

SharePoint:

此部分略。與安卓無關。

Web服務庫：

? ? ? ?一個常見的數(shù)據(jù)后臺存儲是由line-of-business(LOB)應用程序公開的商業(yè)服務。通常來說，這些商業(yè)服務是對于普通數(shù)據(jù)庫CRUD操作更高層次的抽象。然而，從客戶端的角度來說，

? ? ? ? ? 他們通常等同于數(shù)據(jù)源。與SharePoint列表相似，訪問網(wǎng)絡服務可以是復雜并且容易出錯的。通過使用repository集中訪問服務的邏輯并且提供一個單元測試的替代點。請注意，服務的調(diào)用通常很昂貴，并且受益于在repository實現(xiàn)的緩存策略。（也就是通過本地緩存減少服務的調(diào)用）

下圖展示了使用緩存的服務后端存儲庫：

? ? ? ?在這種情況下，repository的查詢邏輯先檢查緩存中是否有需要的數(shù)據(jù)，如果沒有，repository訪問網(wǎng)絡服務區(qū)獲取信息。雖然可以直接訪問服務，但也可以通過SharePoint的業(yè)務數(shù)據(jù)目錄去訪問（SharePoint Business Data Catalog (BDC)）。BDC可以合并一些數(shù)據(jù)源（包括網(wǎng)絡服務），然后通過統(tǒng)一通用的接口暴露它們。BDC允許你去使用標準的網(wǎng)絡不見去展示或修改數(shù)據(jù)。

Repository Examples：

略。

注意事項：

Repository模式增加了你代碼中的抽象層次。這會導致你的代碼難以被你的同事去理解，盡管實現(xiàn)該模式減少了代碼冗余，但他通常會增加需要被維護的類的數(shù)量。

Repository模式幫助我們?nèi)ジ綦x服務和列表訪問的代碼。通過這種隔離，更容易將它們視為獨立的服務，并在單元測試當中用模擬對象去替代它們。通常來說，很難對repository本身進行單元測試，所以盡量去為他們編寫集成測試。

當你在多線程環(huán)境中緩存數(shù)據(jù)時，除了緩存對象之外，還要考慮同步對緩存的訪問呢。一般來說，常見緩存（ASP.NET的緩存），是線程安全的，但你也要確保對象自身可以在多線程環(huán)境中操作。

如果你在高負載系統(tǒng)中緩存數(shù)據(jù)，性能可能是一個問題，嘗試對數(shù)據(jù)源進行同步訪問，這確保了只有單個數(shù)據(jù)請求被發(fā)送到列表或后臺服務。其他的客戶端依賴于檢索的數(shù)據(jù)。