使用IOC容器有什么优点和缺点？

Question

使用IOC容器会降低应用程序的速度，因为它们中的大多数使用反射。他们也可以让你的代码更难理解（？）。光明的一面;它们帮助您创建更松散耦合的应用程序，并使单元测试更加轻松。使用/不使用IOC容器是否有其他优点和缺点？

Answer 1

在大多数情况下，您甚至不会注意到性能损失，因为对于“单例”对象，所有初始化仅执行一次。我还会争辩说，IoC使它不同于理解代码：相反，IoC风格的开发迫使你创建小型连贯类，而这又反过来更容易理解。

Answer 2

嗯，我想我所经历的一个骗局是，有些开发人员似乎无法掌握IoC。我们有几个人无缘无故地反对它，除了他们不了解他们。 （并不是说这是违反某些事情的糟糕理由，根本不是。）

它确实增加了一点抽象，总是会让某人或其他人感到困惑，但我会说专业人士远远超过了利弊在多数情况下。

Answer 3

如果您以简单的方式使用IOC容器，则仅在启动时使用反射 - 应用程序已启动，然后按正常运行，无需任何容器干预。当然，如果您在开始运行后使用IOC来解决依赖性问题，这可能会稍微有点不同 - 尽管我仍然期望它能够解决懒惰和缓存问题，除非您将它配置为每个都创建新的实例时间。

至于使代码更难理解 - 恰恰相反！通过明确声明的依赖关系，理解每个组件会更容易，并且配置文件会清楚说明整个应用程序如何挂起在一起。

Answer 4

我同意迄今为止所有的答案。

我想补充的是，它会产生一些开销，所以它不适合小应用程序。

中型和大型应用程序从使用IoC中受益最大。

您也可以看看这个问题上的优点和缺点的详细信息：Castle Windsor Are There Any Downsides?

Answer 5

我相信关于降低执行速度的假设是大致相同的一种说法为“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详细）。传统的方法是将它作为参数发送，放在线程本地或请求服务。有了弹簧，您可以直接将其注射到需要它的地方，而不需要其他人知道。

这实际上改变了整个应用程序开发。我真的很难适应这种情况，但在这种痛苦之后，我发现它确实更接近事情的发展方向（而不是我们如何学会这样做）。

所以我认为DI框架有可能改变你制作程序的方式，并且不仅仅是DI，而且还有更深入的影响。这不仅是一种叫新荣耀的方式。

Answer 6

我认为如果您对如何使用IOC有所认识并倾向于编写好的代码，那么IOC将使您的代码更容易理解除最小系统以外的所有代码。

但是，如果您正在某个大多数类/方法非常大且重构概念尚未成熟的地方工作，那么尝试使用IOC很可能只会让软件难以理解。国际奥委会也必须由每个参与项目计划的人来承担，这可能是一个考虑因素。

我看到国际奥委会是锦上添花;我喜欢结冰，但只能在一个不错的蛋糕上。如果蛋糕开始时不好，先把蛋糕弄清楚。

至于使用IOC的性能开销，在大多数情况下，我不认为这是一个问题。开销不必很大，并且考虑到当今CPU的速度，大部分运行时间很可能都是数据访问。如果一个IOC被证明对于给定的一段代码变慢，我会考虑添加一些缓存返回的对象，或者从这段代码中删除IOC 只是。

Answer 7

如果您正在编写业务应用程序，那么使用反向控制和依赖注入容器（结合其他敏捷实践和工具）将帮助您提高生产力和可靠性。此外，您的应用程序可能会花费绝大部分CPU时间等待资源或等待人机交互，并且无用。您的应用程序应该有足够的功率来备用几微秒的反射。