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

Question

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

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

看来，存储库并不是这些方法的最佳位置。

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

将这些查询放在哪里？

Answer 1

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

以下是马丁·福勒如何定义它的方法：

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

存储库在域和数据映射层之间进行中介，其作用就像内存中的域对象集合。客户端对象以声明的方式构造查询规范，并将它们提交给仓库以获得满意。对象可以添加到Repository中并从Repository中移除，就像它们可以从简单的对象集合中添加一样，并且由Repository封装的映射代码将在幕后执行适当的操作。从概念上讲，存储库封装了数据存储中持久化的一组对象以及在它们上执行的操作，从而提供了一个更面向对象的持久化层视图。存储库还支持实现域层和数据映射层之间的清晰分离和单向依赖的目标。

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

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

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

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

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

像存储库这样的模式比GoF模式要宽一些。这使得基于存储库位的意见。此外，在DDD上下文之外，存储库也被广泛使用。这进一步增加了人们的意见。

看来，存储库并不是这些方法的最佳位置。

如果你这么认为，而且你在设计这些方法时有更好的位置，那就继续把那些方法移到那个地方。如果您的设计告诉您，存储库是这些方法的最佳位置，请毫不犹豫地使用它。

将这些查询放在哪里？

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