design-patterns - 域实体/对象和向其中注入(inject)服务感觉完全错误，有理由吗？

Question

在我看来，感觉就像我们需要在这里反转构造。

实体依靠服务来填充自身内部的各种属性。这应该交给建筑商，不是吗？ (即对象的构造)我正在查看遗留代码并执行一些一般重构。

从本质上讲，实体应该是相当愚蠢的，似乎有混合处理正在进行，我很确定应该/可能会被打破。

Answer 1

将服务注入(inject)域实体可能不是一个好主意，但可能不是你想的那样。

In essence the entity should be pretty dumb, there seems to be mix of processing going on it that Im pretty certain should/could be broken out.

这是一个有争议的问题，但许多人认为哑域实体是一种反模式( Anemic Domain Model)并且违背了面向对象的编程风格。实体不仅应该包含数据，还应该封装行为。

问题是，在您的域对象开始遭受低 cohesion 之前，您可以添加多少行为？ ?在您的示例中，依赖服务来填充各种属性是域对象的职责(内聚性)与非职责之间的典型边界情况。此外，如果属性是从数据库中显式加载的，这可能违反了 persistence ignorance原则。

如果事实证明这些属性需要从对象的诞生开始就被初始化，我同意你的观点，工厂或生成器可能是获取数据和组装实体的更好地方，特别是在构造逻辑复杂的情况下.

但通常情况下，这种机制是为了提供延迟加载，换句话说，可以按需及时地填充属性。这允许推迟昂贵的操作，例如从数据库中获取潜在的大数据，并避免从一开始就将大对象图加载到内存中。

虽然我个人不会因为延迟加载而看到在构建时注入(inject)实体中的服务，但有些人认为这是不好的做法:请参阅 here和 here .您可能更喜欢使用方法注入(inject)或 delegate injection用于更清洁、更可测试的实体。