最近開發的MVC專案使用了Repository模式。

啥是Repository模式？

從圖看，有一個倉庫介面，一個實現了這個倉庫介面的基類；然後在使用方，一方面，要宣告一個繼承於倉庫介面的子介面，另一方面，編寫一個數據庫操作類，繼承倉庫基類，並實現這個子介面。

繼承倉庫基類容易理解，為啥還要搞一個子介面呢？直接實現倉庫介面不就完啦？思考其中原因，應該是為了控制反轉，依賴注入，總之一個類對應一個介面就是了。

Repository模式意義何在呢？

Repository模式是一箇中間層，位於 資料庫對映層 和 領域層（業務邏輯層）之間。本來嘛，ORM或者DAL已經為我們隔離了資料庫，BLL並沒有直接訪問資料庫，如果資料庫更換，那改寫ORM或DAL即可。那麼現在又增加一層Repository，目的何在呢?

摘錄一些話，姑妄聽之。反正他們牛逼，怎麼說都行：

Repository 是一個獨立的層，介於領域層與資料對映層 (資料訪問層) 之間。它的存在讓領域層感覺不到資料訪問層的存在，它提供一個類似集合的介面提供給領域層進行領域物件的訪問。Repository 是倉庫管理員，領域層需要什麼東西只需告訴倉庫管理員，由倉庫管理員把東西拿給它，並不需要知道東西實際放在哪。(咦，難道DAL\ORM不是這樣的嗎？) 
Repository 模式是架構模式，在設計架構時，才有參考價值； 
Repository 模式主要是封裝資料查詢和儲存邏輯； 
Repository 模式實際用途：更換、升級 ORM 引擎，不影響業務邏輯； 
Repository 模式能提高測試效率，單元測試時，用 Mock 物件代替實際的資料庫存取，可以成倍地提高測試用例執行速度。

這幾句話中，好像亮點在於換ORM，比如將NHibernate換成EF，BLL也不受影響。呵呵。

也有一些鑽研者自我安慰： 
使用Repository，隱含著一種意圖傾向，就是 Domain需要什麼我才提供什麼，不該提供的功能就不要提供，一切都是以Domain的需求為核心；而使用Dal，其意圖傾向在於我Dal層能使用的數 據庫訪問操作提供給Business層，你Business要用哪個自己選。換一個Business也可以用我這個Dal，一切是以我Dal能提供什麼操 作為核心。

也有後起之秀頓悟： 
倉儲模式最大的優點就是所有的資料訪問首先是通過倉庫的，對倉庫的增刪改都不會立即提交到資料庫，而只有當呼叫了倉庫包裹器，這些增刪改的操作才會一次提交到資料庫。

但我怎麼看，都看不出這個批量提交、倉庫包裹器與Repository有什麼關係。

今天看到一種隱隱約約的說法，說資源庫（大概就是Repository模式吧）有個好處，就是可以相容快取。BLL通過資源庫來存取資料，而不必知道這些資料是來自於資料庫還是快取。