就我自己而言，使用IoC（并使用外部配置）的主要原因之一是围绕以下两个方面：
- Testing
- Production maintenance
Testing
如果将测试分为3个场景（在大规模开发中这是很正常的）：
- Unit testing
- Integration testing
- Black box testing
对于最后两个测试场景（集成和黑匣子），你需要做的是不重新编译应用程序的任何部分。
如果你的任何测试方案都要求你更改配置（即：使用另一个组件来模拟银行集成或执行性能负载），则可以轻松地进行处理（这确实是在配置服务器的DI端的好处下）。 IoC虽然。
此外，如果你的应用程序在多个站点（具有不同的服务器和组件配置）上使用，或者在实时环境中具有更改的配置，则可以使用以后的测试阶段来验证该应用程序将处理这些更改。
Production
作为开发人员，你没有（也不应该）控制生产环境（尤其是当你的应用分发到多个客户或单独的站点时），这对我来说是同时使用IoC和外部配置的真正好处，因为需要基础架构/生产支持来调整和调整实时环境，而无需回到开发人员手中并通过测试（他们只想移动一个组件就需要更高的成本）。
Summary
IoC的外部配置的主要好处来自赋予其他人（非开发人员）配置应用程序的能力，以我的经验，这仅在少数情况下才有用：
- 应用程序分发到环境会有所不同的多个站点/客户端。
- 对生产环境和设置的有限开发控制/输入。
- 测试方案。
在实践中，我发现即使开发出你可以控制环境的东西，随着时间的流逝，最好还是让其他人来更改配置：
- 开发时，你不知道它何时会更改（该应用程序非常有用，你的公司将其出售给其他人）。
- 我不想每次都要求通过设置和使用良好的配置模型来进行轻微更改时就不得不更改代码。
注意：应用程序指的是完整的解决方案（不仅仅是可执行文件），因此应用程序运行所需的所有文件。
