Ninject之旅之七:Ninject依赖注入

摘要

可以使用不同的模式向消费者类注入依赖项,向构造器里注入依赖项是其中一种。有一些遵循的模式用来注册依赖项,同时有一些需要避免的模式,因为他们经常导致不合乎需要的结果。这篇文章讲述那些跟Ninject功能相关的模式和反模式。然而,全面的介绍可以在Mark Seemann的书《Dependency Injection in .NET》中找到。

1、构造函数注入

构造函数时推荐的最常用的向一个类注册依赖项的模式。一般来说,这种模式应该经常被用作主要的注册模式,除非我们不得不使用其他的模式。在这个模式中,需要在构造函数中引入所有类依赖项列表。

问题是如果一个类有多于一个的构造函数会怎么样。尽管Ninject选择构造函数的策略是可以订制的,他默认的行为是选择那个有更多可以被Ninject解析的参数的构造函数。

因此在下面的例子中,尽管第二个构造函数有更多的参数,如果Ninject不能解析IService2,他将调用第一个构造函数。如果IService1也不能被解析,他将调用默认构造函数。如果两个依赖项都被注册了可以被解析,Ninject将调用第二个构造函数,因为他有更多的参数。

 public class Consumer
{
  private readonly IService1 dependency1;
  private readonly IService2 dependency2;
  public Consumer(IService1 dependency1)
  {
    this.dependency1 = dependency1;
  }
9   public Consumer(IService1 dependency1, IService2 dependency2)
  {
    this.dependency1 = dependency1;
    this.dependency2 = dependency2;
  }
}

如果上一个类中有另一个构造函数也有两个可以被解析的参数,Ninject将抛出一个ActivationException异常,通知多个构造函数有相同的优先级。

有两种方式可以重载默认的行为,显示地选择调用哪一个构造函数。第一种方式是在绑定中指出需要的构造函数:

Bind<Consumer>().ToConstructor(arg => new Consumer(arg.Inject<IService1>()));

另一种方式是在需要的构造函数中使用[Inject]特性:

 [Inject]
public Consumer(IService1 dependency1)
{
  this.dependency1 = dependency1;
}

在上面的例子中,我们再第一个构造函数中使用了[Inject]特性,显式地指定在初始化类中注入依赖项时调用的构造函数。尽管第二个构造函数有更多的参数,按照Ninject默认的策略会选择第二个构造函数。

注意在多个构造函数中同时使用这个特性时会产生ActivationException异常。

2、初始化方法和属性注入
除了构造函数注入之外,Ninject支持通过初始化方法和属性setter依赖注入。我们可以通过[Inject]特性指定任意多的需要的方法和属性来注入依赖项。

尽管依赖项在类一初始化的时候就被注入,但是不能预计依赖项注入的顺序。下面的例子演示如何指定一个属性的注入:

 [Inject]
public IService Service
{
  get { return dependency; }
  set { dependency = value; }
}

下面的例子使用注入方法注册依赖项:

 [Inject]
public void Setup(IService dependency)
{
this.dependency = dependency;
}

注意只有公有成员和公有构造函数才可以被注入,甚至internal的成员都被忽视除非Ninject配置成可以注册非公有成员。

在构造函数注入中,构造函数是单一的点,在这个点上,类被初始化后就可以使用它的所有的依赖项。但是,如果我们使用初始化方法,依赖项通过多个点以无法预期的顺序被注入。因此,不能知道在哪个方法中,所有的依赖项都已经被注入可以使用了。为了解决这个问题,Ninject提供了IInitializable接口。这个接口有一个IInitialize方法,一旦所有的依赖项都被注入,将调用这个方法:

 public class Consumer : IInitializable
{
private IService1 dependency1;
private IService2 dependency2;
[Inject]
public IService Service1
{
get { return dependency1; }
set { dependency1 = value; }
}
[Inject]
public IService Service2
{
  get { return dependency2; }
  set { dependency2 = value; }
}
public void Initialize()
{
  // Consume all dependencies here
}
}

尽管Ninject支持使用属性和方法注入,构造函数注入应该是优先的方式。首先,构造函数注入使类更好的重用性,因为所有的类依赖项的列表是可见的。在初始化属性或方法里,类的使用者需要研究类的所有的成员或者浏览了类说明文档后(如果有的话),才能发现他的依赖项。
当使用构造函数注入的时候,类的初始化更容易。因为所有的依赖项在同一时刻被注入,我们可以很容易地在相同的地方使用这些依赖项。正如我们在前面的例子中看到的那样,在构造函数注入的场景中,注入的字段可能是只读的。因为只读字段只能在构造函数中被初始化,我们需要将他改成可写的,才可以使用初始化方法和属性对他进行注入。这将导致潜在的修改字段可读写属性的问题。
3、服务定位器

服务定位器是Martin Fowler介绍的一种很有争议的设计模式。尽管在一些特定的场景中可能有用,他一般被认为是一种反模式,需要尽可能避免。如果我们不属性这个模式,Ninject很容易地被误用成服务定位器。下面的例子示范误用Ninject kernal成一个服务定位器而不是一个DI容器:

 public class Consumer
{
  public void Consume()
  {
    var kernel = new StandardKernel();
    var depenency1 = kernel.Get<IService1>();
    var depenency2 = kernel.Get<IService2>();
    ...
  }
}

前面的代码有两个重大的缺点。第一个是尽管我们使用一个DI容器,但是我们不可能一直使用DI。这个类跟Ninject kernal绑在一起,然而Ninject kernal并不真的是这个类的依赖项。这个类以及他所有预期的调用类将总是不必要的依赖于kernal对象和Ninject类库。在另一方面,真正的类依赖项(IService1和IService2)对于这个类却不可见,降低了可重用性。即使我们按照下面的方式修改这个类的设计,这个问题仍然存在:

 public class Consumer
{
  private readonly IKernel kernel;
  public Consumer(IKernel kernel)
  {
    this.kernel = kernel;
  }
  public void Consume()
  {
    var depenency1 = kernel.Get<IService1>();
    var depenency2 = kernel.Get<IService2>();
    ...
  }
}

前面的类仍旧依赖于Ninject类库,然后他不必要这样,他真正的依赖项仍然对调用者不可见。可以很容易地使用构造函数注入模式重构:

 public Consumer(IService1 dependency1, IService2 dependency2)
{
  this.dependency1 = dependency1;
  this.dependency2 = dependency2;
}
上一篇:系统根据用户cookies,为用户打上各种标签


下一篇:从Java的角度理解前端框架,nodejs,reactjs,angularjs,requirejs,seajs