inversion-of-control - 反对控制反转容器的论据

Question

似乎每个人都在转向 IoC 容器。我已经尝试“摸索”了一段时间，尽管我不想成为一个在高速公路上走错路的司机，但它仍然没有通过常识对我的考验。让我解释一下，如果我的论点有缺陷，请纠正/启发我:

我的理解:当组合不同的组件时，IoC 容器应该让你的生活更轻松。这是通过 a) 构造函数注入(inject)、b) setter 注入(inject)和 c) 接口(interface)注入(inject)来完成的。然后以编程方式或在容器读取的文件中“连接”它们。然后通过名称召唤组件，然后在需要时手动施放。

我没有得到:

编辑 :(更好的措辞)
如果组件设计得当(使用 IoC 模式、松散耦合)，当您可以(恕我直言)更清晰地“连接”应用程序时，为什么要使用不符合语言习惯的不透明容器？这个“托管代码”如何获得重要的功能？ (我听说过一些关于生命周期管理的提及，但我不一定明白这比自己动手更好/更快。)

原创 :
为什么要竭尽全力将组件存储在容器中，以不符合语言习惯的方式“连接它们”，在按名称调用组件时使用相当于“goto 标签”的东西，然后丢失很多通过手动转换获得静态类型语言的安全优势，当您通过不这样做来获得等效功能时，而是使用现代 OO 语言提供的所有很酷的抽象特性，例如编程到接口(interface)？我的意思是，实际需要使用手头组件的部分必须知道他们在任何情况下都在使用它，在这里您将使用最自然、惯用的方式进行“接线” - 编程!

Answer 1

肯定有people who think that DI Containers add no benefit ，并且这个问题是有效的。如果纯粹从对象组合的角度来看，容器的好处似乎可以忽略不计。任何第三方都可以连接松散耦合的组件。

然而，一旦你超越了玩具场景，你应该意识到连接合作者的第三方必须承担更多的简单责任。还可能存在退役问题以防止资源泄漏。由于 Composer 是唯一知道给定实例是共享还是私有(private)的一方，它还必须承担起 的角色。终身管理 .

当您开始组合各种实例范围、使用共享服务和私有(private)服务的组合，甚至可能将某些服务的范围限定为特定上下文(例如 Web 请求)时，事情就会变得复杂。用穷人的 DI 编写所有代码当然是可能的，但它不会增加任何商业值(value)——它是纯粹的基础设施。

此类基础设施代码构成 通用子域 ，因此创建一个可重用的库来解决这些问题是很自然的。这正是 DI 容器。

顺便说一句，我知道的大多数容器不使用名称来连接自己 - 他们使用 自动接线 ，它将来自构造函数注入(inject)的静态信息与容器从接口(interface)到具体类的映射配置相结合。简而言之，容器本身就理解这些模式。

DI 不需要 DI 容器 - 它非常有用。

更详细的处理可以看文章When to use a DI Container .