3

有人可以解释使用这种模式的好处吗?实体框架4和存储库模式

我的意思是不EF已在某种意义上的存储库?你不能只是查询容器并返回这些对象?

我看到很多关于POCO,AutoMapper,依赖注入,服务层,IoC的讨论。我只是把一堆东西混合在一起,还是都涉及到?

有人可以向我解释这个吗?

此外,这一切如何与MVC.net,ViewModels与DataModels一起使用?

感谢, 山姆

回答

21

还有就是一堆随机问题的存在,所以我给了一堆随机答案:

  • 一个版本库,定义(由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,并解决该问题(可以作为内存列表实现)。
+0

@ RPM1984 - 您可否详细说明#3:_italic_Yes,您可以查询EF容器并返回对象,但这样消费者就会知道基础持久性机制太多了,关心 - 因此存储库模式?_italic_ – Sam 2011-02-18 05:57:32