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容器用于更多的基础设施，这对于高级场景来说是很好的，但在这些情况下，我同意它会使新开发人员难以阅读和调试代码。

我将尝试从我的角度找出为什么IOC可能不好。

As with everything else, IOC container (or as Einstein would put it I=OC^2) is a concept you have to decide for yourself if you need it or not in your code. Recent fashion outcry about IOC is only that, fashion. Don't fall for fashion, that is first. There are myriads of concepts out there you could implement in your code. First of all, I am using dependency injection since I have started programming, and learned the term itself when it was popularized under that name. Dependency control is a very old subject and it was addressed so far in trillions of ways, depending on what was decoupling from what. Decoupling everything from everything is a nonsense. The problem with IOC container is that it tries to be as useful as Entity Framework or NHibernate. While writing an object-relational mapper is simply a must as soon as you have to couple any database with your system, IOC container is not always necessary. So when IOC container is useful:

当你有很多依赖的情况，你想组织 当你不关心你的代码与第三方产品的耦合时 当您的开发人员想要学习如何使用新工具时

1:在你的代码中有这么多依赖关系并不常见，或者你在设计的早期就意识到了它们。当需要抽象思维时，抽象思维是有用的。

2:将你的代码与第三方代码耦合是一个巨大的问题。我使用的是10多年前的代码，当时遵循的是ATL、COM、COM+等花哨而先进的概念。现在你对这些代码无能为力了。我想说的是，一个先进的概念会带来明显的优势，但从长远来看，这种优势本身就过时了。这只会让一切都变得更贵。

3: Software development is hard enough. You can extend it to unrecognizable levels if you allow some advanced concept to crop into your code. There is a problem with IOC2. Although it is decoupling dependencies, it is decoupling the logic flow as well. Imagine you have found a bug and you need to set a break to examine the situation. IOC2, as any other advanced concept, is making that more difficult. Fixing a bug within a concept is more difficult than fixing a bug in a plainer code, because when you fix a bug a concept must be obeyed again. (Just to give you an example, C++ .NET is constantly changing the syntax so much that you need to think hard before you refactor some older version of .NET.) So what is the problem with IOC? The problem is in resolving dependencies. The logic for resolving is commonly hidden in the IOC2 itself, written maybe in uncommon way that you need to learn and maintain. Will your third-party product be there in 5 years? Microsoft's was not.

"We know how" syndrome is written all over the place regarding IOC2. This is similar to automation testing. Fancy term and perfect solution at first glance, you simply put all your tests to execute over night and see the results in the morning. It is really painful to explain company after company what automated testing really means. Automated testing is definitely not a quick way of reducing the number of bugs which you can introduce overnight to increase the quality of your product. But, fashion is making that notion annoyingly dominant. IOC2 suffers the same syndrome. It is believed that you need to implement it in order your software to be good. EvErY recent interview I was asked if I am implementing IOC2 and automation. That is a sign of fashion: the company had some part of code written in MFC they will not abandon.

你需要像学习软件中的其他概念一样学习IOC2。是否需要使用IOC2是由团队和公司内部决定的。但是，在做出决定之前，至少必须提到以上所有的理由。只有当你看到积极的一面超过消极的一面，你才能做出积极的决定。

There is nothing wrong with IOC2 except that it does solve only the problems it solves and introduces the problems it introduces. Nothing else. However, going against the fashion is very difficult, they have sweat mouth, the followers of anything. It is strange how none of them is there when the problem with their fanciness becomes apparent. Many concepts in software industry have been defended because they create profit, books are written, conferences held, new products made. That is fashion, usually short lived. As soon as people find something else they abandon it completely. IOC2 is useful but it shows the same signs as many other vanished concepts I have seen. I do not know if it will survive. There is no rule for that. You think if it is useful, it will survive. No, it does not go that way. One big rich company is enough and the concept can die within few weeks. We'll see. NHibernate survived, EF came second. Maybe IOC2 will survive too. Do not forget that most concepts in software development are about nothing special, they are very logical, simple and obvious, and sometimes it is more difficult to remember the current naming convention than to understand the concept itself. Does the knowledge of IOC2 make a developer a better developer? No, because if a developer was not able to come up with a concept similar in nature to IOC2 then it will be difficult for him or her to understand which problem IOC2 is solving, using it will look artificial and he or she may start using it for sake of being some sort of politically correct.

在我看来，您已经构建了自己的IoC容器(使用Martin Fowler描述的各种模式)，并且正在询问为什么其他人的实现比您的更好。

所以，你有一堆已经工作的代码。并且想知道为什么要用其他人的实现来替换它。

考虑第三方IoC容器的优点

你可以免费修理bug 图书馆的设计可能比你的好 人们可能已经熟悉了特定的库 图书馆可能比你的快 它可能有一些您希望实现但没有时间实现的特性(您有服务定位器吗?)

Cons

你可以免费引入bug:) 图书馆的设计可能比你的还差 你必须学习一个新的API 太多你永远不会用到的功能 调试不是你写的代码通常比较困难 从以前的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容器，您的代码将变得(坦白地说)难以阅读。为了弄清楚代码要做什么，您必须查看的地方的数量至少增加了一个。在天堂的某个地方，一位天使在呼喊。

我认为IoC的大部分价值都是通过使用DI获得的。既然你已经这样做了，剩下的好处是递增的。

你得到的值将取决于你正在处理的应用程序的类型:

For multi-tenant, the IoC container can take care of some of the infrastructure code for loading different client resources. When you need a component that is client specific, use a custom selector to do handle the logic and don't worry about it from your client code. You can certainly build this yourself but here's an example of how an IoC can help. With many points of extensibility, the IoC can be used to load components from configuration. This is a common thing to build but tools are provided by the container. If you want to use AOP for some cross-cutting concerns, the IoC provides hooks to intercept method invocations. This is less commonly done ad-hoc on projects but the IoC makes it easier.

我以前写过这样的功能，但如果我现在需要这些功能中的任何一个，我宁愿使用一个预先构建并经过测试的工具，如果它适合我的架构的话。

正如其他人所提到的，您还可以集中配置希望使用的类。虽然这可能是一件好事，但代价是误导和复杂化。大多数应用程序的核心组件都没有被替换，因此很难做出取舍。

我使用IoC容器，并欣赏其功能，但不得不承认我注意到了权衡:我的代码在类级别变得更加清晰，而在应用程序级别变得不那么清晰(即可视化控制流)。