将依赖注入到域模型中的技术答案

【问题标题】：Techniques for dependency injection into a domain model将依赖注入到域模型中的技术
【发布时间】：2011-03-22 02:20:54
【问题描述】：

我有一个域模型类型。它的众多属性之一需要 ITranslationService 提供将其返回值翻译成适当语言的能力。

我是否应该将 ITranslationService 注入到域模型类型的构造函数中（因此必须在实例化类型的任何地方进行更改，并且在通过 NhIbernate 检索时必须关注初始化），即使它被一小部分使用类型（许多属性之一）；还是我可以使用另一种功能模式？

有没有人有相关经验可以分享？

【问题讨论】：

【解决方案1】：

我应该注入 ITranslationService 进入领域模型类型的构造函数

是的，这可能有意义，具体取决于您的情况。如果您总是避免将服务注入实体，那么这可能会导致 anemic domain model 这是一种反模式。

需要实例化实体的代码可以通过使用工厂来屏蔽额外的构造函数参数，该工厂负责依赖注入。

【讨论】：

【解决方案2】：

我不希望域对象进行翻译 - 相反，使用域对象（或相关属性值）作为参数的翻译服务，并返回翻译后的值。例如，你可以简单地做

var translatedString = yourServiceInstance.Translate(theDomainObject.Property);

【讨论】：

+1 这样更好。另一种设计听起来违反了 SRP。
我对您的回答的理解是您将对翻译服务的依赖转移到方法的客户端？您的代码看起来与属性中的代码完全一样。我的问题是提供依赖。一种可能是将翻译服务注入新的访问器方法。将访问器/修改器方法对公开为休眠属性是否直接？ ...我觉得我的深度不够
@Ben：是的，将依赖项移至使用域对象的对象，而不是将其放在对象本身中。如果这是一个 ASP.NET MVC Web 应用程序，我会想象上面的代码在控制器操作或视图中。这样做的目的是让您的域对象只保存数据，而其他人负责处理该数据。
@Tomas - 我明白你在说什么。尽管试图避免贫血模型存在紧张关系。
域实体是否需要翻译才能执行其目的，还是用户界面问题？贫血领域模型是暴露其所有内部状态以供修改并且缺乏特定领域行为的实体。实体不需要，在我看来也不应该使用注入服务来提供行为。