關於Repository模式
關於Repository模式
轉自：http://www.cnblogs.com/dudu/archive/2011/05/25/repository_pattern.html
定義（來自Martin Fowler的《企業應用架構模式》）：
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
個人理解：Repository是一個獨立的層，介於領域層與資料對映層（資料訪問層）之間。它的存在讓領域層感覺不到資料訪問層的存在，它提供一個類似集合的介面提供給領域層進行領域物件的訪問。Repository是倉庫管理員，領域層需要什麼東西只需告訴倉庫管理員，由倉庫管理員把東西拿給它，並不需要知道東西實際放在哪。
1. Repository模式是架構模式，在設計架構時，才有參考價值；
2. Repository模式主要是封裝資料查詢和儲存邏輯；
3. Repository模式實際用途：更換、升級ORM引擎，不影響業務邏輯；
4. Repository模式能提高測試效率，單元測試時，用Mock物件代替實際的資料庫存取，可以成倍地提高測試用例執行速度。
評估：應用Repository模式所帶來的好處，遠高於實現這個模式所增加的程式碼。只要專案分層，都應當使用這個模式。
關於泛型Repository介面（來源）：
僅使用泛型Repository介面並不太合適，因為Repository介面是提供給Domain層的操作契約，不同的entity對於Domain來說可能有不同的操作約束。因此Repository介面還是應該單獨針對每個Eneity類來定義。
泛型的Repository<T>類仍然用來減少重複程式碼，只是不能被UserRepository類直接繼承，因為這樣Delete方法將侵入User類，所以改為在UserRepository中 組合一個Repository<T>，將開放給domain可見且又能使用泛型重用的功能委託給這個Repository<T>
Repository與Dal的區別（來源）：
Repository是DDD中的概念，強調Repository是受Domain驅動的，Repository中定義的功能要體現Domain的意圖和約束，而Dal更純粹的就是提供資料訪問的功能,並不嚴格受限於Business層。
使用Repository，隱含著一種意圖傾向，就是 Domain需要什麼我才提供什麼，不該提供的功能就不要提供，一切都是以Domain的需求為核心；而使用Dal，其意圖傾向在於我Dal層能使用的數 據庫訪問操作提供給Business層，你Business要用哪個自己選。換一個Business也可以用我這個Dal，一切是以我Dal能提供什麼操 作為核心。