您是否将存储库注入到域对象中？答案

【问题标题】：Do you inject a Repository into Domain Objects?您是否将存储库注入到域对象中？
【发布时间】：2012-12-20 00:00:56
【问题描述】：

在一天学习 10 多个小时的领域驱动设计一周后，我开始觉得自己已经开始很好地理解它了，直到今天读到这篇文章：

那篇文章的作者说您将存储库注入到域对象中，这对我来说没有任何意义。

我不是这方面的专家，但我认为他错了，但我希望这里的一些人就将存储库注入域对象是否正确或错误提供一些意见。

上周我每天都在阅读，因为我阅读了另一篇文章，另一篇文章对我来说听起来都一样（这是一件好事），直到我看到我在上面发布的文章，如果我的文章让我三思而后行此图案的图片不正确。

您是否应该注入存储库？

【问题讨论】：

DDD - the rule that Entities can't access Repositories directly的可能重复
总而言之：这不仅是一种不好的做法，而且他的示例也很糟糕（除非您要求存储库进行一些计算/计数，否则 UserRepository 必须返回 User 对象的实例）。
感谢您的回复。是的，我认为他根本不应该写关于 DDD 的文章。至少现在我知道，如果我能意识到什么时候有人做错了，我实际上已经在上周学到了一些关于 DDD 的知识。虽然我相信我很快会回来回答更多问题，但仍然不是 100% 满意。
类似讨论stackoverflow.com/questions/14020196/…

【解决方案1】：

显示的示例使用Active Record pattern。在这种模式中，实体知道如何自救。这通常被认为不好Separation of Concerns，因为该类知道两件事：数据属性和如何自我持久化。

将存储库注入 Active Record 对象比我见过的一些 Active Record 实现更好（因为您至少可以换出存储库实现），但在我看来（以及大多数 DDD 社区）依赖是向后：

存储库应该依赖于它返回的对象，而不是另一个绕路。这样做的原因是您的“域对象”（更多关于以后）可以存在（并且应该是可测试的）而无需加载或已保存（即依赖于存储库）。

所以回答你的问题，不。您不应该将存储库注入到域对象中。

然而，值得注意的是，这并不是一个真正的领域对象，因为它没有行为 - 只是简单的 get/sets（访问器/突变器）。这只是一个Data Transfer Object (DTO)。如果真的没有行为，则不需要域模型 - 它只是简单的 CRUD。

【讨论】：

所以假设，我使用弹性搜索来实现一些搜索行为，那么所有的搜索行为都来自 ES，我不需要真正的业务逻辑。所以我应该只使用DTO。（我使用单独的对象进行搜索，它只包括搜索所需的字段）。
是的，基本上。这是我今天在类中建模的方法：- SearchRequest（普通旧 DTO）- SearchRequestHandler（使用一种方法：Handle()，依赖于 ES）- SearchResponse（普通旧 DTO）