依赖注入仅用于测试或生产？

Question

依赖注入框架是仅用于测试还是用于生产代码？似乎一旦你开始使用像ninject这样的框架，你就不会想要扭转一切。另外，使用像ninject这样的东西会有性能影响吗？

Answer 1

依赖注入是一种体系结构模式，而不是测试模式。因此，它旨在用于构建生产代码。事实上，一个非常好的框架引入了很小的开销，如果有的话。不能确定ninject或unity是否如此，我曾经实现过自己的。

DI的可能真正缺点主要在于编码过程，而不是生产性能。应该提到一个：当使用DI时，你失去了使用'Go to Definition'来完成代码的能力 - 它总能带你进入非常合乎逻辑但仍无法使用的界面。

Answer 2

您肯定在生产环境中使用DI。在测试环境中，只需为测试目的进行连接，实际上，如果您使用模拟对象，您可能 自行连接类。

Answer 3

用于一切！为什么反过来呢？质量框架的性能损失应该只在启动时发生。此外，可能会有一个轻微的惩罚，直到VM可以内联额外的层。无论哪种方式，您都可以看到错误的减少和开发人员生产力的提高。

DI特别适合生产。在我们的软件中，我们在生产中使用与测试中完全相同的配置。

运行测试时，测试配置只会将某些服务标记为被模拟。这意味着测试配置为：

1. 列出模拟服务
2. 为模拟的服务方法指定各种方法调用的返回值。

测试好处：

1. 生产和测试之间没有配置差异意味着没有可能出现潜在的配置依赖性错误
2. 服务也会注入Test类。
3. 测试配置很简单（仅在服务被模拟的情况下才需要）
4. 测试配置始终与生产相同。 （更容易维护）
5. 服务初始化绝不是手动的，而是一起黑客攻击。

生产福利：

1. 清理启动代码 - 没有硬编码依赖项
2. 循环依赖不是问题。
3. 能够“关闭”服务的本地副本并将请求路由到其他框。 （用于后台批处理任务）