【发布时间】：2010-10-05 14:57:23
【问题描述】：
使用 IOC 容器会降低应用程序的速度，因为它们中的大多数都在后台使用反射。它们还可以使您的代码更难理解（？）。在亮的一边;它们帮助您创建更松散耦合的应用程序并使单元测试更容易。使用/不使用 IOC 容器还有其他优缺点吗？
【问题讨论】：
标签： inversion-of-control ioc-container
【发布时间】：2010-10-05 14:57:23
【问题描述】：
如果您以简单的方式使用 IOC 容器，则反射仅在启动时使用 - 应用程序在启动时已连接好，然后它会正常运行而无需容器的任何干预。当然，如果您在开始运行后使用 IOC 来解决依赖关系，那可能会略有不同 - 尽管我仍然希望它能够延迟解析并缓存，除非您已将其配置为每个都创建新实例时间。
至于让代码更难理解——恰恰相反！明确说明依赖关系后，更容易理解每个组件，并且配置文件清楚地表明了整个应用程序是如何连接在一起的。
【讨论】：
-
使用 IoC 容器后，代码更容易理解。然而，在他们使用它之前，一些开发人员可能很难理解他们为什么需要它。它解决的复杂性问题通常不存在于玩具应用程序中。
-
我同意和不同意：独立的片段在孤立的情况下更容易理解。但整个画面和布线更加困难。示例：您正在阅读调用存储库保存方法的服务的源代码。我问你的编辑器“保存的转到定义”你最终在接口定义中而不是在使用的具体实现中。
-
@k3b：当然，所以您还需要了解管道......但我认为这不足以使不同的服务相互紧密耦合是值得的.
-
@JonSkeet 我知道这是一个老问题和评论，但是：它不是“IoC 或紧密耦合”。简而言之，我们可以拥有适当的模块化代码，并且可以控制分支。
好吧，我想我遇到的一个问题是一些开发人员似乎无法掌握 IoC。我们有一些人无缘无故地反对它，除了他们不理解它们。 （并不是说这是反对某事的坏理由，一点也不。）
它确实添加了一些抽象，似乎总是设法使某人或其他人感到困惑，但我想说在大多数情况下利大于弊。
【讨论】：
我认为公平地说，如果您对如何使用 IOC 有专业的了解并且倾向于编写好的代码，那么 IOC 将使您的代码在除最小系统之外的所有系统上都更易于理解。
但是，如果您在大多数类/方法都非常大且重构概念尚未普及的地方工作，那么尝试使用 IOC 可能只会使软件更难理解。国际奥委会也必须得到参与该项目的每个人的学习，所以这可能是一个考虑因素。
我认为国际奥委会是锦上添花；我喜欢糖霜，但只在一个漂亮的蛋糕上。如果蛋糕不好吃，先把蛋糕整理好。
至于使用 IOC 的性能开销，在大多数情况下我不认为这是一个问题。开销不需要很大，考虑到当今 CPU 的速度，大多数人的运行时间很可能是数据访问。如果 IOC 被证明对于给定的一段代码变慢了，我会考虑添加一些返回对象的缓存，或者从那段代码中删除 IOC just。
【讨论】：
我相信关于降低执行速度的假设与“C 比 C#/Java 更快”的论点大致相同。虽然此陈述可能适用于特定操作和/或结构简单的任务，但复杂性上升时并非如此。
DI 框架让您专注于对象创建和依赖关系的方式可以在代码大小增加时创建更高效的系统。对于大型应用程序，我几乎可以肯定基于 DI 框架的代码将胜过任何替代解决方案。运行时的冗余太少了，很难提高效率！大多数额外开销也只是在首次加载时。
高级 DI 容器还让您可以在没有容器的情况下实现“范围”魔法。使用范围代理，spring 可以执行以下操作：
A Singleton
|
B Singleton
|
C Prototype (per-invocation)
|
D Singleton
|
E Session scope (web app)
|
F Singleton
实际上，您可以拥有十层单例对象，然后突然出现会话范围内的某些内容。
可以以与其他方式完全不同的方式注入安全性之类的东西。通常有一个经典的悖论：GUI 层通常需要对安全权限有复杂的了解。服务层通常也需要这个，但通常在不同的细节级别（通常不如 gui 详细）。经典的方法是将其作为参数发送，将其放在线程本地或询问服务。使用 spring，您可以将其直接注入您需要的地方，其他人不需要知道。
这实际上改变了整个应用程序开发。我很难适应这一点，但在经历了这种痛苦之后，我发现它确实更接近于事情应该如何（而不是我们学会如何去做）。
因此，我认为 DI 框架有可能改变您制作程序的方式，其影响远不止 DI。这不仅仅是一种称谓新的美化方式。
【讨论】：
我同意到目前为止的所有答案。
我想补充的是，它会产生一些开销，因此它并不适合小型应用程序。
中型和大型应用程序从使用 IoC 中获益最多。
您还可以查看此问题以了解有关利弊的更多信息：Castle Windsor Are There Any Downsides?
【讨论】：
在大多数情况下，您甚至不会注意到性能损失，因为对于“单例”对象，所有初始化只执行一次。我还认为 IoC 使理解代码变得不同：相反，IoC 风格的开发迫使您创建小的连贯类，而这些类反过来更容易理解。
【讨论】：
如果您正在编写业务应用程序，使用控制反转和依赖注入容器（结合其他敏捷实践和工具）将帮助您提高生产力和可靠性。
此外，您的应用程序可能会将其大部分 CPU 时间用于等待资源或等待人机交互，而没有做任何有用的事情。您的应用程序应该有足够的能力来进行几微秒的反射。
【讨论】：