最近開發的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通過資源庫來存取數據，而不必知道這些數據是來自於數據庫還是緩存。
