存储库模式最佳实践

Question

因此，我在应用程序中实现存储库模式，并在我对该模式的理解中遇到了两个“问题”：

1. 查询 - 我读到了在使用存储库时不应使用 IQueryable 的回复。但是，很明显您希望每次调用方法时都不会返回完整的对象列表。是否应该实施？如果我有一个名为 List 的 IEnumerable 方法，那么 IQueryable 的一般“最佳实践”是什么？它应该/不应该有哪些参数？

2. 标量值 - 返回单个标量值而不必返回整个记录的最佳方法（使用存储库模式）是什么？从性能的角度来看，在整行中仅返回单个标量值不是更有效吗？

Answer 1

严格来说，存储库提供用于获取/放置域对象的集合语义。它提供了围绕物化实现（ORM、手动、模拟）的抽象，以便域对象的使用者与这些细节解耦。在实践中，存储库通常抽象对实体的访问，即具有身份的域对象，并且通常是持久生命周期（在 DDD 风格中，存储库提供对聚合根的访问）。

存储库的最小界面如下：

void Add(T entity);
void Remove(T entity);
T GetById(object id);
IEnumerable<T> Find(Specification spec);

尽管您会看到命名差异以及 Save/SaveOrUpdate 语义的添加，但以上是“纯粹”的想法。您将获得 ICollection 添加/删除成员以及一些查找器。如果您不使用 IQueryable，您还会在存储库中看到查找器方法，例如：

FindCustomersHavingOrders();
FindCustomersHavingPremiumStatus();

在此上下文中使用 IQueryable 存在两个相关问题。第一个是可能以域对象关系的形式向客户端泄露实现细节，即违反德米特定律。第二个是存储库获得了查找可能不属于域对象存储库本身的职责，例如，查找与所请求的域对象相关而不是与相关数据相关的投影。

此外，使用 IQueryable “打破”了这种模式：具有 IQueryable 的存储库可能会也可能不会提供对“域对象”的访问。 IQueryable 为客户端提供了很多关于最终执行查询时将具体化什么的选项。这是有关使用 IQueryable 的争论的主旨。

关于标量值，您不应使用存储库来返回标量值。如果您需要标量，通常可以从实体本身获取它。如果这听起来效率低下，确实如此，但您可能不会注意到，具体取决于您的负载特征/要求。如果由于性能原因或需要合并来自多个域对象的数据而需要域对象的备用视图，则有两种选择。

1) 使用实体的存储库查找指定的实体并将其投影/映射到扁平化视图。

2) 创建一个专用于返回封装所需扁平视图的新域类型的查找器接口。这不会是一个存储库，因为不会有集合语义，但它可能会在幕后使用现有的存储库。

如果您使用“纯”存储库来访问持久化实体，需要考虑的一件事是您会损害 ORM 的一些好处。在“纯”实现中，客户端无法提供如何使用域对象的上下文，因此您无法告诉存储库：“嘿，我只是要更改 customer.Name 属性，所以不要这样做”不必费心去获取那些急切的参考资料。另一方面，问题是客户是否应该了解这些东西。这是一把双刃剑。

就使用 IQueryable 而言，大多数人似乎都愿意“打破”模式以获得动态查询组合的好处，特别是对于分页/排序等客户端职责。在这种情况下，您可能会：

Add(T entity);
Remove(T entity);
T GetById(object id);
IQueryable<T> Find();

然后您可以取消所有这些自定义 Finder 方法，随着查询需求的增长，这些方法确实会使存储库变得混乱。

Answer 2

作为对@lordur的回应，我真的不喜欢指定存储库接口的事实上的方法。

因为解决方案中的接口要求每个存储库实现至少需要一个 Add、Remove、GetById 等。现在考虑一个场景，其中通过存储库的特定实例进行保存没有意义，您仍然必须实现其余方法带有 NotImplementedException 或类似的内容。

我更喜欢像这样分割我的存储库接口声明：

interface ICanAdd<T>
{
    T Add(T entity);
}

interface ICanRemove<T>
{
    bool Remove(T entity);
}

interface ICanGetById<T>
{
    T Get(int id);
}

SomeClass 实体的特定存储库实现可能如下所示：

interface ISomeRepository
    : ICanAdd<SomeClass>, 
      ICanRemove<SomeClass>
{
    SomeClass Add(SomeClass entity);
    bool Remove(SomeClass entity);
}

让我们退后一步，看看为什么我认为这是比实现所有 CRUD 方法更好的实践一个通用接口。

有些对象有不同的
要求比别人高。一位顾客
对象不能被删除，a
无法更新采购订单，并且
ShoppingCart 对象只能是
创建的。当一个人使用通用的
IRepository接口这个
显然会导致问题
执行。

那些实施反模式的人
通常会充分实施
然后接口会抛出异常
对于他们不知道的方法
支持。除了不同意
这违反了许多面向对象的原则
他们希望能够利用他们的
IRepository有效抽象
除非他们也开始放置方法
无论是否给定对象
予以支持并进一步落实
他们。

此问题的常见解决方法是
转向更精细的界面
例如 ICanDelete、ICanUpdate、
ICanCreate 等等等此时
解决许多问题
在 OO 方面兴起的
原理也大大减少了
正在重用的代码量
大多数时候人们不会
能够使用存储库
不再具体实例。

我们都不喜欢编写相同的代码
一遍又一遍。然而一个存储库
如同建筑接缝一样收缩
是错误的地方来扩大
合同以使其更加通用。

这些摘录无耻地摘自这篇文章 您还可以在评论中阅读更多讨论。

Answer 3

关于1：
据我所知，从存储库返回的问题不是 IQuerable 本身。存储库的要点是它应该看起来像一个包含所有数据的对象。所以你可以向存储库询问数据。如果您有多个对象需要相同的数据，则存储库的工作就是缓存数据，因此存储库的两个客户端将获得相同的实例 - 因此，如果一个客户端更改属性，另一个客户端将看到该数据，因为它们指向同一个实例。

如果存储库实际上是 Linq 提供程序本身，那么这就很合适。但大多数人只是让 Linq-to-sql 提供程序的 IQuerable 直接通过，这实际上绕过了存储库的责任。所以存储库根本不是存储库，至少根据我对模式的理解和使用。

关于2：
当然，仅从数据库返回单个值比返回整个记录更具性能效率。但是使用存储库模式，您根本不会返回记录，而是返回业务对象。因此应用程序逻辑不应该关心字段，而应该关心域对象。

但是，与完整的域对象相比，返回单个值有多有效呢？如果您的数据库模式定义得相当好，您可能无法衡量差异。

拥有干净、易于理解的代码比预先进行微观性能优化要重要得多。