關於MVC架構中的Repository模式 關於MVC架構中的Repository模式 關於MVC架構中的Repository模式 關於MVC架構中的Repository模式 個人理解：Repository是一個獨立的層，介於領域層與數據映射層（數據訪問層）之間。它的存在讓領域層感覺不到數據訪問層的 ...
關於MVC架構中的Repository模式
個人理解：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能提供什麼操 作為核心。
為了構建更加適應未來變化以及更加易於測試的MVC應用程式，你應該考慮使用Repository模式。當你使用Repository模式時，你會創建一個獨立的repository類，它包含了所有的數據訪問邏輯。
當你創建repository類時，你創建了一個介面，該介面代表著所有由repository類所使用的方法。在你的控制器中，你針對介面編寫代碼，而不是針對repository。通過這種方式，你以後可以使用不同的數據訪問技術來實現repository。
