我已经使用依赖注入(DI)有一段时间了，在构造函数、属性或方法中进行注入。我从未觉得有必要使用反转控制(IoC)容器。然而，我读得越多，我就越感到来自社区的使用IoC容器的压力。
我使用过StructureMap、NInject、Unity和Funq等。net容器。我仍然没有看到IoC容器将如何受益/改进我的代码。
我也害怕在工作中开始使用容器，因为我的许多同事会看到他们不理解的代码。他们中的许多人可能不愿意学习新技术。
请说服我，我需要使用IoC容器。当我在工作中与其他开发人员交谈时，我将使用这些论点。
当前回答
对我来说，使用IoC容器的最大好处(我个人使用Ninject)是消除了设置和其他类型的全局状态对象的传递。
我不为web编程，我的是一个控制台应用程序，在对象树的许多地方，我需要访问用户指定的设置或元数据，这些设置或元数据是在对象树的一个完全独立的分支上创建的。通过IoC，我简单地告诉Ninject将设置作为一个单例(因为它们总是只有一个实例)，在构造函数中请求设置或字典，然后立即…它们在我需要的时候神奇地出现了!
如果不使用IoC容器，我将不得不通过2,3，…传递设置和/或元数据。在它被需要它的对象实际使用之前，有n个对象。
DI/IoC容器还有许多其他好处，正如其他人在这里详细介绍的那样，从创建对象到请求对象的想法可能会令人难以置信，但使用DI对我和我的团队非常有帮助，所以也许您可以将其添加到您的库中!
其他回答
我支持你，瓦迪姆。IoC容器采用了一个简单、优雅且有用的概念，并使其成为您需要用200页手册学习两天的东西。
我个人很困惑，为什么IoC社区把Martin Fowler写的一篇漂亮、优雅的文章变成了一堆复杂的框架，通常只有200-300页的手册。
我尽量不去评判(哈哈!)，但我认为使用IoC容器的人(A)非常聪明，(B)对不如他们聪明的人缺乏同理心。对他们来说，每件事都很有意义，所以他们很难理解许多普通程序员会感到困惑的概念。这是知识的诅咒。理解IoC容器的人很难相信还有人不理解它。
The most valuable benefit of using an IoC container is that you can have a configuration switch in one place which lets you change between, say, test mode and production mode. For example, suppose you have two versions of your database access classes... one version which logged aggressively and did a lot of validation, which you used during development, and another version without logging or validation that was screamingly fast for production. It is nice to be able to switch between them in one place. On the other hand, this is a fairly trivial problem easily handled in a simpler way without the complexity of IoC containers.
我相信如果您使用IoC容器，您的代码将变得(坦白地说)难以阅读。为了弄清楚代码要做什么，您必须查看的地方的数量至少增加了一个。在天堂的某个地方，一位天使在呼喊。
我是声明式编程的爱好者(看看我回答了多少SQL问题)，但我所研究的IoC容器似乎太神秘了。
.．.或者IoC容器的开发人员无法编写清晰的文档。
.．.或者两者在某种程度上都是正确的。
我不认为IoC容器的概念不好。但是实现必须足够强大(即灵活)，以便在各种各样的应用程序中都有用，同时又要简单易懂。
可能是其他的六个中的六个。真正的应用程序(不是玩具或演示)必然是复杂的，会有许多极端情况和规则的例外。您可以将这种复杂性封装在命令式代码中，也可以封装在声明式代码中。但你必须在某个地方表示它。
关于Unity也是如此。如果房子太大，你会听到房梁的吱吱声。
当人们开始大谈IoC代码看起来有多干净时，我从不感到惊讶，这些人在90年代曾说过c++中的模板是如何优雅的方式，但现在却会谴责它们是神秘的。呸!
As you continue to decouple your classes and invert your dependencies, the classes continue to stay small and the "dependency graph" continues to grow in size. (This isn't bad.) Using basic features of an IoC container makes wiring up all these objects trivial, but doing it manually can get very burdensome. For example, what if I want to create a new instance of "Foo" but it needs a "Bar". And a "Bar" needs an "A", "B", and "C". And each of those need 3 other things, etc etc. (yes, I can't come up with good fake names :) ).
使用IoC容器为您构建对象图可以大大降低复杂性，并将其推到一次性配置中。我只需说“给我创建一个Foo”，它就会计算出构建一个Foo需要什么。
有些人将IoC容器用于更多的基础设施，这对于高级场景来说是很好的，但在这些情况下，我同意它会使新开发人员难以阅读和调试代码。
想必没有人强迫您使用依赖注入容器框架。您已经使用DI来解耦类并改进可测试性，因此您将获得许多好处。简而言之，你喜欢简单，这通常是件好事。
如果您的系统达到了一个复杂的水平，手动DI变成了一件苦差事(也就是说，增加了维护)，请将其与DI容器框架的团队学习曲线进行权衡。
如果您需要对依赖生命周期管理进行更多的控制(也就是说，如果您觉得需要实现单例模式)，请查看DI容器。
如果使用DI容器，请只使用需要的特性。跳过XML配置文件，在代码中配置即可。坚持构造函数注入。Unity或StructureMap的基本内容可以压缩到几个页面中。
Mark Seemann写了一篇很棒的博文:什么时候使用DI容器
