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的最大好处是能够集中配置依赖项。

如果你正在使用依赖注入，你的代码可能是这样的

public class CustomerPresenter
{
  public CustomerPresenter() : this(new CustomerView(), new CustomerService())
  {}

  public CustomerPresenter(ICustomerView view, ICustomerService service)
  {
    // init view/service fields
  }
  // readonly view/service fields
}

如果你使用静态IoC类，而不是(恕我直言)更混乱的配置文件，你可以有这样的东西:

public class CustomerPresenter
{
  public CustomerPresenter() : this(IoC.Resolve<ICustomerView>(), IoC.Resolve<ICustomerService>())
  {}

  public CustomerPresenter(ICustomerView view, ICustomerService service)
  {
    // init view/service fields
  }
  // readonly view/service fields
}

然后，你的静态IoC类看起来像这样，我在这里使用Unity。

public static IoC
{
   private static readonly IUnityContainer _container;
   static IoC()
   {
     InitializeIoC();
   }

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerView, CustomerView>();
      _container.RegisterType<ICustomerService, CustomerService>();
      // all other RegisterTypes and RegisterInstances can go here in one file.
      // one place to change dependencies is good.
   }
}

我是声明式编程的爱好者(看看我回答了多少SQL问题)，但我所研究的IoC容器似乎太神秘了。

.．.或者IoC容器的开发人员无法编写清晰的文档。

.．.或者两者在某种程度上都是正确的。

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

想必没有人强迫您使用依赖注入容器框架。您已经使用DI来解耦类并改进可测试性，因此您将获得许多好处。简而言之，你喜欢简单，这通常是件好事。

如果您的系统达到了一个复杂的水平，手动DI变成了一件苦差事(也就是说，增加了维护)，请将其与DI容器框架的团队学习曲线进行权衡。

如果您需要对依赖生命周期管理进行更多的控制(也就是说，如果您觉得需要实现单例模式)，请查看DI容器。

如果使用DI容器，请只使用需要的特性。跳过XML配置文件，在代码中配置即可。坚持构造函数注入。Unity或StructureMap的基本内容可以压缩到几个页面中。

Mark Seemann写了一篇很棒的博文:什么时候使用DI容器

我只是碰巧正在把自己生长的DI代码拉出来，并用IOC替换它。我可能已经删除了200多行代码，用大约10行代码替换了它。是的，我必须学习如何使用容器(Winsor)，但我是一名在21世纪从事互联网技术工作的工程师，所以我已经习惯了。我大概花了20分钟看了一下怎么做。这很值得我花时间。