无论何时使用“new”关键字，您都是在创建一个具体的类依赖，您的头脑中应该敲响警钟。孤立地测试这个物体变得更加困难。解决方案是对接口进行编程并注入依赖项，这样对象就可以用实现该接口的任何东西进行单元测试。模拟)。

The trouble is you have to construct objects somewhere. A Factory pattern is one way to shift the coupling out of your POXOs (Plain Old "insert your OO language here" Objects). If you and your co-workers are all writing code like this then an IoC container is the next "Incremental Improvement" you can make to your codebase. It'll shift all that nasty Factory boilerplate code out of your clean objects and business logic. They'll get it and love it. Heck, give a company talk on why you love it and get everyone enthused.

如果你的同事还没有做DI，那么我建议你先专注于DI。宣传如何编写易于测试的干净代码。干净的DI代码是比较困难的部分，一旦做到了这一点，将对象连接逻辑从Factory类转移到IoC容器应该是相对简单的。

IoC容器也适用于装入嵌套很深的类依赖项。例如，如果你有以下代码使用依赖注入。

public void GetPresenter()
{
    var presenter = new CustomerPresenter(new CustomerService(new CustomerRepository(new DB())));
}

class CustomerPresenter
{
    private readonly ICustomerService service;
    public CustomerPresenter(ICustomerService service)
    {
        this.service = service;
    }
}

class CustomerService
{
    private readonly IRespository<Customer> repository;
    public CustomerService(IRespository<Customer> repository)
    {
        this.repository = repository;
    }
}

class CustomerRepository : IRespository<Customer>
{
    private readonly DB db;
    public CustomerRepository(DB db)
    {
        this.db = db;
    }
}

class DB { }

如果你把所有这些依赖都加载到一个IoC容器中，你可以解析CustomerService，所有的子依赖都会自动得到解析。

例如:

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

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerService, CustomerService>();
      _container.RegisterType<IRepository<Customer>, CustomerRepository>();
   }

   static T Resolve<T>()
   {
      return _container.Resolve<T>();
   }
}

public void GetPresenter()
{
   var presenter = IoC.Resolve<CustomerPresenter>();
   // presenter is loaded and all of its nested child dependencies 
   // are automatically injected
   // -
   // Also, note that only the Interfaces need to be registered
   // the concrete types like DB and CustomerPresenter will automatically 
   // resolve.
}

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

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

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

我不认为IoC容器的概念不好。但是实现必须足够强大(即灵活)，以便在各种各样的应用程序中都有用，同时又要简单易懂。

可能是其他的六个中的六个。真正的应用程序(不是玩具或演示)必然是复杂的，会有许多极端情况和规则的例外。您可以将这种复杂性封装在命令式代码中，也可以封装在声明式代码中。但你必须在某个地方表示它。

IoC框架非常棒，如果你想…

…扔掉类型安全。许多(?)IoC框架迫使您执行代码，如果您想确保所有东西都正确连接。“嘿!希望我已经把一切都设置好了，这样我对这100个类的初始化就不会在生产中失败，抛出空指针异常!” .．.在代码中使用全局变量(IoC框架都是关于改变全局状态的)。 .．.编写依赖关系不明确、难以重构的蹩脚代码，因为你永远不知道什么依赖什么。

IoC的问题在于，使用它的人过去常常编写这样的代码

public class Foo {
    public Bar Apa {get;set;}
    Foo() {
        Apa = new Bar();
    }
}

这显然是有缺陷的，因为Foo和Bar之间的依赖是硬连接的。然后他们意识到编写这样的代码会更好

public class Foo {
    public IBar Apa {get;set;}
    Foo() {
        Apa = IoC<IBar>();
    }
}

这也有缺陷，但不那么明显。 在Haskell中，Foo()的类型将是IO Foo，但你真的不想要IO部分，这应该是一个警告信号，如果你得到了它，你的设计有问题。

为了摆脱它(io部分)，获得ioc框架的所有优点，去掉它的所有缺点，你可以使用抽象工厂。

正确的解决方法应该是

data Foo = Foo { apa :: Bar }

或者

data Foo = forall b. (IBar b) => Foo { apa :: b }

和inject(但我不会叫它inject) Bar。

另外:观看Erik Meijer (LINQ的发明者)的视频，他说DI是为不懂数学的人准备的(我非常同意):http://www.youtube.com/watch?v=8Mttjyf-8P4

不像Spolsky先生，我不相信使用ioc框架的人很聪明——我只是认为他们不懂数学。

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

关于Unity也是如此。如果房子太大，你会听到房梁的吱吱声。

当人们开始大谈IoC代码看起来有多干净时，我从不感到惊讶，这些人在90年代曾说过c++中的模板是如何优雅的方式，但现在却会谴责它们是神秘的。呸!