我们是否需要依赖注入模型

Question

今天，我和我的同事讨论了模型的依赖注入问题。他坚信有一个模型的DI。因为他不想拥有具体的对象。

但我的感受...... DI仅在我们可以用其他方式替换实现的情况下才需要。在商业模式的情况下，它是固定的（如果模型是用于汽车，它将解决仅汽车的问题..）并且不能像其他技术实施那样被替换..

我是正确的还是实施商业模式的DI有什么意义？我觉得不必为每个模型创建界面，因为模型没有任何行为，只有DTO。

请建议。

Answer 1

我很少需要为数据模型对象创建接口。由于数据通常是应用程序的动态部分（例如，从数据库中读取或从服务调用中对XML进行编组后），因此在首次构建应用程序组件时，它实际上并不存在，这是您将使用的最常见的位置DI。这就是为什么在XML和JSON中表示抽象通常不可行的原因。您需要添加其他自定义数据元素以标识类型以解决歧义。

所以在我看来，数据模型的DI是过度的。也就是说，您应该始终拥有一个工厂，并明确区分业务逻辑和数据来源。

Answer 2

“只有在我们可以用其他方法替换实现的情况下才需要DI。”

我同意，Wikipedia，“依赖注入模式的主要目的是允许在运行时选择给定依赖关系接口的多个实现... ”

除非实际存在多个实现，否则DI几乎没有任何好处。 也许最常见的答案（例如When to use Dependency Injection）是总有两种实现：一种用于生产，一种用于测试。但是，现代测试框架可以有效地模拟依赖关系而无需单独的DI框架。