Architecture 存储库模式中与集合接口不相关的查询

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

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

似乎存储库不是这些方法的最佳场所

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

---

在哪里放置这些查询？

坦率地说，所有这些存储库内容都是基于意见的

以下是它的定义：

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

存储库在域和数据映射层之间进行中介，就像内存中的域对象集合一样。客户机对象以声明方式构造查询规范，并将其提交到存储库以满足需求。对象可以添加到存储库中，也可以从存储库中删除，就像它们可以从简单的对象集合中删除一样，存储库封装的映射代码将在幕后执行适当的操作。从概念上讲，存储库封装了数据存储中持久化的对象集以及在这些对象上执行的操作，从而提供了持久化层更面向对象的视图。存储库还支持在域和数据映射层之间实现干净分离和单向依赖的目标

正如你在问题中指出的那样：

但我经常看到存储库的接口包含封装复杂查询的方法，这些方法和集合接口无关

在我看来，在DDD上下文中，存储库应该按照您在问题中解释（收集接口）的方式工作。Rest是业务逻辑，应该转移到域模型或服务

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

模式是好的，我们必须遵循这些模式。这些都是由专家根据他们多年的经验构建的。如果同样的问题即将出现，人们应该毫不犹豫地使用它

像repository这样的模式比GoF模式要宽一些。这使得存储库以观点为基础。此外，存储库在DDD上下文之外也被广泛使用。这进一步增加了人们的看法

似乎存储库不是这些方法的最佳场所

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

在哪里放置这些查询

由你决定。关注手头的问题，关注你的设计，关注你的业务需求。不要仅仅为了正确地遵循模式而在代码中添加不必要的复杂性。如果该模式通过修复承诺的问题而产生新问题，那么该模式有何用处