摘要
可以使用不同的模式向消费者类注入依赖项，向构造器里注入依赖项是其中一种。有一些遵循的模式用来注册依赖项，同时有一些需要避免的模式，因为他们经常导致不合乎需要的结果。这篇文章讲述那些跟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;
}