很长一段时间以来，我一直在使用基于接口/继承的多态来设计应用程序，以获得松散耦合的代码。据我所知（到目前为止），DI框架/ IoC仅仅提供了使其“更容易”的工具，但是，额外的抽象级别似乎是多余的，并且会花费额外的开销。
我能想到的唯一原因是，如果一个大型团队已经了解特定的DI / IoC框架，那么每个人都可以在同一页面上。
从我的角度来看，DI似乎与界面设计做同样的事情，我希望还有更多的东西，有人能解释为什么使用DI / IoC框架是一个更好的策略吗？
我真的希望我对DI / IoC说错了。
答案 0 :(得分：5)
首先，您是否可以阅读this required reading并在其中编辑任何缺失点...
如果你期望DI容器a）是非常复杂的野兽或b）一个全新的设计范例，我认为你正在以正常的防御方式做出反应，接近过度炒作的概念。
虽然人们可以投入大量精力以各种各样的神秘方式使用DI容器，并且有很多功能与AOP等重叠，但典型的最佳点是直接自动连接依赖关系“所有团队都需要了解”任何事情或“开销”（你的意思是概念还是性能？如果是后者，你是否测量过实际应用中的影响？）。
但是要理解这一点： - 通过减少摩擦力和增加延展性来实现清洁设计的自由和专注力，因为你扔掉了很多样板代码（如果事情发生变化，还需要重新安装）IOC容器适用于我是发展生态系统的重要组成部分。虽然他们在这里和那里只做了一些new，但他们的影响与他们正在做的实际（小）工作不成比例。
至于它们是否与基于正常接口的编程和良好的设计原则不同，我将它们视为更小的东西 - 一种仅支持SOLID principles之一的工具。
答案 1 :(得分：3)
不，DI / IoC与界面设计不同。
DI / IoC引擎实际上只是一个大型实例工厂。它使您免于编写和维护自己的工作。
这些好处是维护更少（您不必编写）以及更多的查找和报告错误的受众。如果编写DI / IoC引擎的团队比您和您的团队更好，那么您可以使用更高质量的软件。如果您选择的流程比您自己开发的解决方案更广泛，那么外人就有可能知道如何通过阅读广泛使用的书籍来使用它。通过了解并获得知名框架的经验，您团队中的人员将通过增强他们的简历。
我鼓励你继续设计界面，但DI还有更多。