存储库模式方法的标准化

Question

我试图找出存储库模式的正确定义.

我最初的理解是这个(非常愚蠢)

• 将Business Objects与数据对象分开
• 标准化数据访问层中的访问方法.

我确实看到过2种不同的实现方式,并且在网上没有正式的例子,我见过的那些都隐藏在书中.

实施1:

public Interface IRepository<T>{
      List<T> GetAll();
      void Create(T p);
      void Update(T p);
}


public interface IProductRepository: IRepository<Product> {
      //Extension methods if needed
       List<Product> GetProductsByCustomerID();
}

---

实施2:

public interface IProductRepository {
      List<Product> GetAllProducts();
      void CreateProduct(Product p);
      void UpdateProduct(Product p);
      List<Product> GetProductsByCustomerID();
}

请注意,第一个是通用Get/Update/GetAll等,第二个是我将定义的"DAO"更多.

两者都共享数据实体的提取.我喜欢哪个,但我可以用简单的DAO做同样的事情.然而,第二部分标准化我看到的访问操作的价值,如果你实现这个企业范围,人们很容易知道你的存储库的访问方法集.

我错误地认为数据访问的标准化是这种模式的一个组成部分吗？如果两者都正确,为什么选择执行2？

Rhino有一篇关于实现1的好文章,当然MS有一个模糊的定义,实现2的例子在这里.

Answer 1

我是第二个由oded引用的福勒引用.我想指出他说的是"收藏式 "界面.你如何实现像界面这样的集合当然取决于你,但你既不能也不应该试图隐藏它代表远程数据源的事实.因此,它与内存中集合显着不同,内存集合不需要刷新对远程数据存储的更改.ORM的更改跟踪机制或您自己的滚动解决方案决定了对调用者的透明程度.删除通常需要明确标记,插入是可发现的(可达性持久性),有时也需要明确标记更新.将它与您的聚合根的复杂依赖关系结合起来,你会发现它不是那样的集合.

没有"cannonical repository implementation"这样的东西.

通用存储库基类的拥护者和喜欢自己实现每个存储库的人之间经常发生争执.虽然通用实现在简单的场景中很有吸引力,但您经常会发现它是一个非常漏洞的抽象.例如,您的某些聚合可能只是软删除(通过虚方法覆盖可分解),而其他聚合可能根本不支持删除操作.

在决定采用哪条路线之前,请确保了解每种方法的含义.Greg Young在通用存储库的优点上发表了很好的帖子.

http://codebetter.com/blogs/gregyoung/archive/2009/01/16/ddd-the-generic-repository.aspx

Answer 2

从Martin Fowler"企业应用程序架构的模式",存储库模式的定义是:

使用类似集合的接口访问域对象,在域和数据映射层之间进行调解.

所以,这两种方法都是正确的.