存储库模式实现

Question

似乎我找到了存储库模式的每个例子,实现在某种程度上是不同的.以下是我主要找到的两个例子.

interface IProductRepository
{
    IQueryable<Product> FindAll();
}

然后通常有另一层与存储库通信并调用FindAll()方法并执行任何操作,例如查找以字母's'开头的产品或获取特定类别中的产品.

另一个例子我发现很多将所有的find方法都放入了存储库

interface IProductRepository
{
    IEnumerable<Product> GetProductsInCategory(int categoryId);
    IEnumerable<Product> GetProductsStartingWith(string letter);
    IEnumerable<PromoCode> GetProductPromoCodes(int productId);
}

你建议我选择哪条路？或者彼此的优点/缺点是什么？

根据我的理解,阅读http://martinfowler.com/eaaCatalog/repository.html第一种方法似乎最能反映这一点？

Answer 1

第一个是可怕的.IQueryable就像一个GOD对象.很难找到100%完整的实现(即使在所有OR/Ms中).您可以直接公开ORM而不是使用它,因为否则您可能会获得泄漏的抽象层.

乔尔说得最好(文字来自维基百科文章):

在Spolsky的文章中,他提到了许多关于抽象的例子,这些抽象在大多数时候都有效,但是底层复杂性的细节不容忽视,从而将复杂性推向了本应被抽象本身简化的软件.

Joels博客文章

第二种方法更容易实现,并保持抽象完整.

更新

您的存储库违反了单一责任原则,因为它有两个原因需要更改.第一个是如果更改Products API,另一个是更改PromoCode API.您应该使用两个不同的存储库,例如:

interface IProductRepository
{
    IEnumerable<Product> FindForCategory(int categoryId);
    IEnumerable<Product> FindAllStartingWith(string letter);
}

interface IPromoCodeRepository
{
    IEnumerable<PromoCode> FindForProduct(int productId);
}

换了东西:

• 我倾向于Find在返回多个项目时以及Get如果返回单个项目时开始方法.
• 更短的方法名称=更容易阅读.
• 单一责任.更容易分辨使用存储库的类对依赖项的影响.

小的定义好的接口可以更容易地发现违反SOLID原则的行为,因为类中断原则往往会使得构造函数变得臃肿.