Ninject之旅之十：Ninject自定义提供者

摘要

提供者是特殊的工厂类，Ninject使用它来实例化解析类型。任何时候我们绑定一个服务类型到一个组件，我们都隐式地关联那个服务类型到一个可以实例化那个组件的提供者。这个隐藏的提供者被称为StandardProvider，是一个通用的工厂，他可以创建每一个给定类型的实例。尽管我们可以经常依赖StandardProvider而不用对他在背后做了什么费心，Ninject也允许我们创建和注册我们自己自定义的提供者，只要我们需要自定义这个下面的激活过程：

 Bind<IService>().ToProvider<MyService>();
 public class MyServiceProvider : Provider<MyService>
 {
     protected override MyService CreateInstance(IContext context)
     {
         return new MyService();
     }
 }

尽管继承这个Provider<T>类是推荐的方法来创建一个自定义提供者。作为一个提供者，为一个类继承这个IProvider接口在Ninject就足够了：

 public interface IProvider
 {
     Type Type { get; }
     object Create(IContext context);
 }

回顾上一篇文章的ShippersSqlRepository类和ShippersXmlRepository类，他们的的构造函数都有一个字符串类型的参数。

ShippersSqlRepository构造函数参数northwindConnectionString提供连接字符串：

 public class ShippersSqlRepository : IShippersRepository
 {
     private readonly NorthwindContext objectContext;
     public ShippersSqlRepository(string northwindConnectionString)
     {
         objectContext = new NorthwindContext(northwindConnectionString);
     }
     public IEnumerable<Business.Model.Shipper> GetShippers()
     { ... }
     public void AddShipper(Business.Model.Shipper shipper)
     { ... }
 }

ShippersXmlRepository构造函数参数xmlRepositoryPath提供xml文件路径：

 public class ShippersXmlRepository : IShippersRepository
 {
     private readonly string documentPath;
     public ShippersXmlRepository(string xmlRepositoryPath)
     {
         this.documentPath = xmlRepositoryPath;
     }
     public IEnumerable<Shipper> GetShippers()
     { ... }
     public void AddShipper(Shipper shipper)
     { ... }
 }

在这个情况下，这些参数阻止了Ninject实例化我们的repository，因为这个kernel对怎样解析字符串参数没有任何主意。因此，下面几行对于注册我们的repository还不够：

 　　Bind<IShippersRepository>().To<ShippersSqlRepository>()
 　　.When(r => r.Target.Name.StartsWith("source"));
 　　Bind<IShippersRepository>().To<ShippersXmlRepository>()
 　　.When(r => r.Target.Name.StartsWith("target"));

一个提供需要的参数的方法是使用这个WithConstructorArgument方法：

     connection = ConfigurationManager.AppSettings["northwindConnectionString"];
     Bind<IShippersRepository>()
     .To<ShippersSqlRepository>()
     .When(r => r.Target.Name.StartsWith("source"))
     .WithConstructorArgument("NorthwindConnectionString", connection);
     path = ConfigurationManager.ConnectionStrings["xmlRepositoryPath"];
     Bind<IShippersRepository>()
     .To<ShippersXmlRepository>()
 9     .When(r => r.Target.Name.StartsWith("target"))
     .WithConstructorArgument("XmlRepositoryPath",path);

它看起来很好，这时候我们不需要注册很多需要这样的配置的repository。然而，在更复杂的情况下，我们需要以某种方式自动注入这些参数。这里所有的这些设置是字符串的实例。因此，我们可以为字符串类型创建一个提供者，基于参数名称来生成我们的配置字符串。这个提供者将在应用程序配置文件（web.config或者app.config）的键里查找参数名，如果这样的一个配置是定义好的（像下面代码一样），它就返回它的值：

 using Ninject.Activation;
 using System;
 using System.Configuration;

 namespace DataMigration.Business.Provider
 {
     public class ConfigurationProvider : Provider<string>
     {
         protected override string CreateInstance(IContext context)
         {
             if (context.Request.Target == null)
             {
                 throw new Exception("Target required.");
             }
             var paramName = context.Request.Target.Name;
             string value = ConfigurationManager.AppSettings[paramName];
             if (string.IsNullOrEmpty(value))
             {
                 value = ConfigurationManager.ConnectionStrings[paramName] == null ? ""
                     : ConfigurationManager.ConnectionStrings[paramName].ConnectionString;
             }
             return value;
         }
     }
 }

ConfigurationProvider被提供了一个包含了当前激活过程所有信息的context对象，包含在这篇文章之前提到过的请求对象。这个请求对象包含目标信息。在这种情况下，目标信息是哪个注入的字符串对象作为构造函数参数。如果被请求的字符串类型是直接从kernel使用Get<string>()方法请求的，目标对象将为空。因为我们需要参数名称作为配置键，我们首先检查目标。使用目标名称，我们可以查找AppSettings，如果我们没有找到这样一个配置，我们将继续在ConnectionStrings部分查找。最后，返回得到的值。

唯一的问题是这个提供者将被注册为字符串类型，他将影响到将要被Ninject解析的任何字符串。为了明确规定是那些将要被认为是应用程序配置的字符串，我们定义一个自定义特性，像下面这样在那些参数上运用它：

 using System;

 namespace DataMigration.Business.Attributes
 {
     [AttributeUsage(AttributeTargets.Property | AttributeTargets.Field | AttributeTargets.Parameter)]
     public class ConfigurationAttribute : Attribute { }
 }

我们已经声明了这个特性只能运用在属性和参数上。下面是这个特性怎样运用到我们repository类构造函数参数上：

 　　　　 public ShippersSqlRepository([Configuration]string connectionString)
         {
             _context = new NorthwindContext(connectionString);
         }

  　　　　public ShippersXmlRepository([Configuration]string xmlRepositoryPath)
         {
             this.documentPath = xmlRepositoryPath;
         }

最后，绑定代码像下面这样：

          Bind<string>().ToProvider<ConfigurationProvider>().WhenTargetHas<ConfigurationAttribute>();

激活上下文

当我们的提供者重载这个CreateInstance方法，我们使用这个上下文context对象，通过方法参数传入。这个对象的类继承IContext接口，这个接口包含了非常多所有跟当前激活过程相关的信息。使用这个对象，我们可以访问当前绑定对象，正在被解析的类型，正在被注入的类型，我们当前在依赖图的什么位置，谁请求了这个解析，等等。在解析一个依赖图的时候，为每一个正在解析的类型创建一个上下文对象，这就导致了一个激活上下文图。从每一个上下文对象开始，我们也可以从他的父上下文节点导航，直到到达图的根，就是最初的发起请求的点。在使用Niinject时，任何我们需要决定怎样解析依赖的地方上下文对象都是可以得到的。

工厂方法

工厂方法是另一个通知Ninject怎样解析一个依赖。像创建一个提供者一样，我们已经访问了这个激活上下文对象，来帮助我们做出决定怎样解析请求类型。然而，我们不需要创建一个新类，我们可以只是内联地写出我们的解析逻辑。工程方法是提供者类的一个很好的替代，在这里解析逻辑是简单和简短的。一个好的使用工厂方法的例子是在一个类里实例化一个日志对象。下面是不使用DI实例化一个日志对象的代码：

 class ConsumerClass
 {
     private ILog log = LogManager.GetLogger(typeof(ConsumerClass));
 }

我们可以在前面的类中使用下面的代码实现DI：

 class ConsumerClass
 {
     private ILog log;
     public ConsumerClass(ILog log)
     {
         this.log = log;
     }
 }    

为ILogger接口用To<T>()方法注册一个类型绑定是不合适的，因为具体的日志对象必须通过调用LogManager.GetLogger方法来创建，而不是通过具体日志类的构造函数。在这种情况下，我们可以使用一个工厂方法来通知Ninject创建一个新日志对象：

 Bind<ILog>().ToMethod(ctx => LogManager.GetLogger(ctx.Request.ParentRequest.Service));

这个ctx的类型是IContext，我们从这个Ninject激活上下文父请求的服务属性中，得到消费者类的类型。