不需要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.

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

在我看来，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.
   }
}

使用容器主要是将命令式/脚本化的初始化和配置风格改为声明式的。这可能会有一些不同的有益影响:

减少主程序启动的繁琐程序。 支持相当深入的部署时重新配置功能。 使依赖注入样式成为新工作阻力最小的路径。

当然，可能会有困难:

需要复杂启动/关闭/生命周期管理的代码可能不容易适应容器。 你可能需要处理个人、流程和团队文化方面的问题——但这就是你为什么要问…… 一些工具包本身正在迅速成为重量级的工具，鼓励了许多依赖注入容器开始反对的那种深度依赖。

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

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

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

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

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