今天，我与同事讨论了模型的依赖注入。他坚信将 DI 用于模型。因为他不想有具体的对象创建。
但是我的感觉.. DI 仅在我们可以用其他实现替换的情况下才需要。在商业模型的情况下，它是固定的（如果模型是用于汽车的，它将只解决汽车的问题..）并且不能像其他技术实现一样被替换..
我是正确的还是对商业模式实施 DI 有什么意义？我觉得没有必要为每个模型创建接口，因为模型没有任何行为，只有 DTO。
请指教。
【问题讨论】：
标签： design-patterns architecture dependency-injection domain-driven-design
“DI [is] 只有在我们可以用其他实现替换的情况下才需要。”
我同意，Wikipedia 也同意，“依赖注入模式的主要目的是允许在运行时在给定依赖接口的多个实现中进行选择......” p>
除非实际上有多种实现，否则 DI 几乎没有什么好处。 也许最常见的答案（例如When to use Dependency Injection）是总是有两种实现：一种用于生产，一种用于测试。但是，现代测试框架可以有效地模拟依赖项，而无需单独的 DI 框架。
【讨论】：
我很少需要为数据模型对象创建接口。并且由于数据通常是应用程序的动态部分（例如，从数据库读取或从服务调用进行后编组 XML），因此在首次构建应用程序组件时它并不真正存在，这是您最常使用的地方DI。这就是为什么用 XML 和 JSON 表示抽象通常不可行的原因。您需要添加其他自定义数据元素来识别类型以解决歧义。
所以在我看来，数据模型的 DI 是矫枉过正的。也就是说，您应该始终在业务逻辑和数据来源之间建立工厂并明确分离。
【讨论】：