實體框架4和存儲庫模式

Question

有人可以解釋使用這種模式的好處嗎？

我的意思是不EF已在某種意義上的存儲庫？你不能只是查詢容器並返回這些對象？

我看到很多關於POCO，AutoMapper，依賴注入，服務層，IoC的討論。我只是把一堆東西混合在一起，還是都涉及到？

有人可以向我解釋這個嗎？

此外，這一切如何與MVC.net，ViewModels與DataModels一起使用？

感謝， 山姆

Answer 1

還有就是一堆隨機問題的存在，所以我給了一堆隨機答案：

• 一個版本庫，定義（由Martin Fowler）爲「介導在域和數據映射層之間使用類似集合的接口訪問域對象「EF是一個ORM，它是數據映射層是的，你可以查詢EF容器並返回對象，但是n當消費者不應該知道/關心時，消費者「知道得太多」，因此存儲庫模式
• POCO's是一種用於從持久性元數據中釋放對象的技術（默認使用EF代碼gen ）。他們還允許您的POCO以您的域名模式加倍。
• ViewModels由MVC Views使用。
• AutoMapper用於將ViewModels輕鬆轉換爲域模型。
• 服務層提供控制器和知識庫之間的中間地帶 - 專門用於IQueryable<T>知識庫，以將查詢實現爲具體的序列（例如ICollection<T>）。
• IoC用於解耦組件之間的依賴關係，它提供了良好/乾淨的體系結構和最高的可測試性（您可以通過Mock庫傳遞給控制器​​，以單元測試它們）。

細化請求上＃3

示例控制器WITHOUT存儲庫：

public class ProductsController 
{ 
    public ActionResult GetProduct(int productId) 
    { 
     Product p; 

     using (var ctx = new MySecretContextWhichIsNowExposed()) 
     { 
      p = ctx.Products.SingleOrDefault(x => x.ProductId == productId); 
     } 

     return View(p); 
    } 
} 

問題與上述：

1. 所述控制器被直接與實體的工作框架對象上下文，這意味着W eb應用程序知道它，並且需要參考System.Data.Entity。
2. 單元測試幾乎是不可能的。您將針對實際的數據庫進行測試，使其成爲集成測試而不是單元測試。
3. 控制器具有「如何檢索單個產品」的邏輯，當它不應該 - 這是域/存儲庫邏輯。

示例控制器WITH庫（和IOC）：

public class ProductsController 
{ 
    private readonly IProductsRepository _repo; 

    public ProductsController(IProductsRepository repo) 
    { 
     _repo = repo; 
    } 

    public ActionResult GetProduct(int productId) 
    { 
     Product p = _repo.FindById(productId); 
     return View(p); 
    } 
} 

爲什麼以上更好：

1. 控制器不具有關於EF想法。不依賴於System.Data.Entity。
2. 控制器不知道存儲庫的實現，它通過一個接口工作。
3. 控制器不提供有關如何檢索產品的邏輯，只有id。
4. 2行簡單代碼。
5. 測試單位=小菜一碟。通過ctor中的MockProductRepository，並解決該問題（可以作爲內存列表實現）。