在我看来，感觉就像我们需要在这里反转构造。
实体依靠服务来填充自身内部的各种属性。这应该交给建筑商，不是吗？（即对象的构造）我正在查看遗留代码并执行一些一般重构。
从本质上讲，实体应该是相当愚蠢的，似乎有混合处理正在进行，我很确定应该/可能会被打破。
问问题
1982 次
1 回答
3
将服务注入域实体可能不是一个好主意，但可能不是你想的那样。
从本质上讲，实体应该是相当愚蠢的，似乎有混合处理正在进行，我很确定应该/可能会被打破。
这是一个有争议的问题，但许多人认为哑域实体是一种反模式（贫血域模型）并且违背了面向对象的编程风格。实体不仅应该包含数据，还应该封装行为。
问题是，在您的域对象开始遭受低内聚之前，您可以添加多少行为？在您的示例中，依赖服务来填充各种属性是域对象的职责（内聚性）与非职责之间的典型边界情况。此外，如果属性是从数据库中显式加载的，这可能违反了持久性无知原则。
如果事实证明这些属性需要从对象的诞生开始就被初始化，我同意你的观点，工厂或生成器可能是获取数据和组装实体的更好地方，特别是在构造逻辑复杂的情况下.
但通常，这种机制是用来提供延迟加载的，换句话说，是按需及时地填充属性。这允许推迟昂贵的操作，例如从数据库中获取潜在的大数据，并避免从一开始就将大对象图加载到内存中。
虽然我个人不会因为延迟加载而看到在构建时注入实体中的服务，但有些人认为这是不好的做法：请参阅此处和此处。您可能更喜欢使用方法注入或委托注入来获得更清洁、更可测试的实体。
于 2012-07-26T12:30:10.767 回答