相关疑难解决方法(0)

这两种模式看起来都像是控制反转原理的实现.也就是说,一个对象不应该知道如何构造它的依赖关系.

依赖注入(DI)似乎使用构造函数或setter来"注入"它的依赖项.

使用构造函数注入的示例:

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

服务定位器似乎使用了一个"容器",它连接了它的依赖关系并给它foo吧.

使用服务定位器的示例:

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo()
  {
    this.bar = Container.Get<IBar>();
  }

  //...
}

因为我们的依赖项只是对象本身,所以这些依赖项具有依赖项,它们具有更多依赖项,依此类推.因此,控制容器的反转(或DI容器)诞生了.示例:Castle Windsor,Ninject,Structure Map,Spring等)

但是,IOC/DI容器看起来完全相同像一个服务定位器.将它称为DI容器是一个坏名字？IOC/DI容器只是另一种服务定位器吗？当我们有很多依赖关系时,我们使用DI容器这一事实的细微差别是什么？