存储库模式中与集合接口无关的查询

Question

存储库代表集合接口。您可以使用存储库存储，删除和查找对象。

但我经常看到存储库的接口包含封装了与集合接口无关的复杂查询的方法。例如：用于复杂计算统计量的方法，该方法返回一些dto。或者使用返回布尔值的mysql进行一些检查，比如“userHasSomething”

似乎存储库不是这些方法的最佳位置。

存储库是否应严格表示集合的接口，还是应该执行与存储相关的所有作业？

在哪里放置这些查询？

Answer 1

坦白说，所有这些存储库的东西都是基于意见的。

以下是Martin Fowler如何定义它：

具有复杂域模型的系统通常受益于一个层，例如Data Mapper（165）提供的层，它将域对象与数据库访问代码的细节隔离开来。在这样的系统中，在映射层上构建另一个抽象层是值得的，其中查询构造代码被集中。当存在大量域类或大量查询时，这变得更加重要。特别是在这些情况下，添加此层有助于最小化重复的查询逻辑

存储库在域和数据映射层之间进行调解，其作用类似于内存中的域对象集合。客户端对象以声明方式构造查询规范，并将它们提交给Repository以满足要求。可以从简单的对象集合中添加和删除对象，因为它们可以从简单的对象集合中删除，并且由存储库封装的映射代码将在后台执行适当的操作。从概念上讲，存储库封装了持久存储在数据存储中的对象集以及对它们执行的操作，从而提供了更加面向对象的持久层视图。存储库还支持在域和数据映射层之间实现清晰分离和单向依赖的目标。

正如您在问题中所述：

但我经常看到存储库的接口包含封装了与集合接口无关的复杂查询的方法。

在我看来，在DDD环境中，存储库应该按照您在问题中解释（收集界面）的方式工作。休息是业务逻辑，应该转移到域模型或服务。

理论仍然是理论;纯粹主义者严格遵循它。最重要的是业务需求。

模式很好，必须遵循这些模式。这些是由专家根据他们多年的经验建立的。如果手头有同样的问题，应该毫不犹豫地使用它。

像存储库这样的模式比GoF模式更广泛。这使得存储库位基于意见。此外，存储库也在DDD上下文之外广泛使用。这进一步加起来了。

似乎存储库不是这些方法的最佳位置。

如果您这么认为并且在设计中有更好的位置，请继续将这些方法移动到那个位置。如果您的设计告诉您存储库是这些方法的最佳位置，请不要犹豫使用它。

在哪里放置这些查询？

由你决定。专注于手头的问题，专注于您的设计，专注于您的业务需求。不要在代码中添加不必要的复杂性，只是为了正确地遵循模式。如果通过修复承诺的模式来创建新问题，该模式的用途是什么？