Entity framework 4 实体框架4和存储库模式

有人能解释一下使用这种模式的好处吗

我的意思是EF在某种意义上已经是一个存储库了吗？你不能直接查询容器并返回那些对象吗

我看到很多关于POCO、AutoMapper、依赖注入、服务层和IoC的讨论。我只是把一堆东西混在一起，还是一切都有关联

有人能给我解释一下吗

另外，这一切如何与MVC.net、ViewModels和DataModels相结合

谢谢，

---

Sam

这里有一堆随机问题，所以我将给出一堆随机答案：

• （Martin Fowler）将存储库定义为“使用类似集合的接口在域和数据映射层之间进行中介，以访问域对象”
• EF是一个ORM，它是数据映射层
• 是的，您可以查询EF容器并返回对象，但是消费者“知道太多”底层持久性机制，而它不应该知道/关心-因此是存储库模式
• POCO是一种用于将对象从持久性元数据中释放出来的技术（默认情况下使用EF code gen）。它们还允许您的POCO兼作您的域模型
• 视图模型由MVC视图使用
• AutoMapper用于轻松地将视图模型转换为域模型
• 服务层在控制器和存储库之间提供了一个中间地带-专门用于

  IQueryable

  存储库，将查询具体化为具体序列（例如

  ICollection

  ）
• IoC用于消除组件之间的依赖关系，这提供了一个良好/干净的体系结构和最高的可测试性（您可以通过模拟存储库将其传递给控制器，以隔离的方式对其进行单元测试）

第3天要求详细说明

不带存储库的示例控制器：

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);
   }
}

上述问题：

控制器直接使用实体框架对象上下文，这意味着Web应用程序知道它，并且需要对System.Data.Entity的引用。

单元测试实际上是不可能的。您将针对实际的数据库进行测试，这使得它成为集成测试而不是单元测试

控制器具有“如何检索单个产品”的逻辑，而它不应该这样做——这是域/存储库逻辑

带有存储库（和IoC）的控制器示例：

为什么以上更好：

控制器不知道EF。不依赖于System.Data.Entity

控制器不知道存储库的实现，它通过一个接口工作

控制器不提供如何检索产品的逻辑，只提供id

2行简单代码

测试单位=小菜一碟。在ctor中通过一个

MockProductRepository

，并完成它（可以作为内存列表实现）

---

@RPM1984-您能否详细说明#3:italic#是的，您可以查询EF容器并返回对象，但是消费者对底层持久性机制“知道得太多”，而它不应该知道/关心—因此是存储库模式_italic@RPM1984-所有这些技术都相关吗？@Sam Striano-是的，它们都有关联。但是有些不是特定于.NET的（POCO的-Java有POJO的，DI/IoC是一个通用的编程原则，存储库/服务层也是如此）。@RPM1984-存储库代码在哪里？在与EF相同的组件中？你能给我举一个分层方法的例子吗？@Sam Striano-这涉及太多，无法给出一个例子，我建议你有一个谷歌“ef4存储库poco”。但是是的，它应该与EF-a“MyCompany.Project.Data”程序集位于同一程序集中。

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);
   }
}