(摘)使用 .NET Core 实现依赖关系注入

为什么使用依赖关系注入？

使用 .net，通过 new 运算符（即，new myservice 或任何想要实例化的对象类型）调用构造函数即可轻松实现对象实例化。遗憾的是，此类调用会强制实施客户端（或应用程序）代码到已实例化对象的紧密耦合的连接（硬编码的引用），此外还会引用其程序集/nuget 包。对于常见的 .net 类型而言，这不是问题。然而，对于提供“服务”（如日志记录、配置、支付、通知或事件 di）的类型，如果你想切换所用服务的实现，则可能不需要依赖关系。例如，一种方案是，客户端可能将 nlog 用于日志记录，而另一种方案是，客户端可能选择 log4net 或 serilog。而且，使用 nlog 的客户端不喜欢使用 serilog 打乱其项目，因此，同时引用两种日志记录服务不会令人满意。

为了解决对服务实现的引用进行硬编码的问题，di 提供了一个间接层，这样与其直接使用 new 运算符实例化服务，倒不如客户端（或应用程序）请求实例的服务集或“工厂”。此外，与其请求特定类型的服务集（例如创建一个紧密耦合的引用），倒不如请求一个接口（如 iloggerfactory），并期待服务提供程序（本例中为 nlog、log4net 或 serilog）实现该接口。

结果是，当客户端直接引用抽象程序集 (logging.abstractions) 时，会同时定义服务接口­，将不需要引用直接实现。

我们将解耦返回到客户端的实际实例的模式称为控制反转。这是因为，与其客户端确定要实例化的对象，就像使用 new 运算符显式调用构造函数时一样，倒不如 di 确定将返回的内容。di 注册了由客户端请求的类型（一般为接口）和将返回的类型之间的关联。此外，di 通常会确定已返回类型的生存期，具体取决于该类型的所有请求之间将有单个共享的实例、每个请求将各有一个新实例，还是介于两者之间。

对 di 的一个尤为常见的需求体现在单元测试中。考虑相应地取决于付款服务的购物车服务。假设编写利用付款服务的购物车服务，并尝试对购物车服务进行单元测试，而不实际调用真实的付款服务。相反，你想调用的是模拟付款服务。为了使用 di 实现此目的，你的代码会从 di 框架请求付款服务接口的实例而不是调用，例如，new paymentservice。然后，只需为单元测试“配置”di 框架，以返回一个模拟付款服务。

相比之下，生产主机可以配置购物车，以使用（可能很多）付款服务选项之一。也许最重要的是，引用将仅针对付款抽象，而不是针对每个具体的实现。

提供“服务”的实例而不是使客户端直接将其实例化是 di 的基本原则。事实上，一些 di 框架允许通过支持基于配置和反射的绑定机制（而不是编译时绑定）从引用实现中对主机进行解耦。这种解耦称为服务定位器模式。

.net core microsoft.extensions.dependencyinjection

若要利用 .net core di 框架，你只需引用 microsoft.extnesions.dependencyinjection.abstractions nuget 包。此包提供了 iservicecollection 接口的入口，从而公开你可以从中调用 getservice<tservice> 的 system.iservice­provider。类型参数 tservice 标识要检索的服务的类型（一般为接口），如下应用程序代码获得了一个实例：

iloggingfactory loggingfactor = serviceprovider.getservice<iloggingfactory>();

有一些相应的非泛型 getservice 方法将 type 作为参数（而不是泛型参数）。泛型方法允许直接分配给特定类型的变量，而非泛型版本需要一个显式转换，因为返回类型为 object。此外，当添加该服务类型时，会有泛型约束，因此使用该类型参数时可以完全避免转换。

如果在调用 getservice 时没有使用收集服务注册任何类型，它将返回 null。这在与 null 传播运算符结合以将可选行为添加到应用时非常有用。类似的 getrequiredservice 方法在没有注册服务类型时会抛出异常。

如你所见，代码非常简单。然而，现在缺少的是如何获得在其上调用 getservice 的服务提供程序的实例。解决方案是首先实例化 servicecollection 的默认构造函数，然后再注册你想要服务提供的类型。图 1 中显示了一个示例，你可以假设其中的每个类（host、application 和 paymentservice）已在单独的程序集中实现。此外，尽管 host 程序集知道要使用哪个记录器，但是没有在 application 或 paymentservice 中引用记录器。同样，host 程序集没有引用 paymentservices 程序集。接口也在单独的“抽象”程序集中实现了。例如，ilogger 接口是在 microsoft.extensions.logging.abstractions 程序集中定义的。

图 1 注册和请求来自依赖关系注入的对象

 

public class host
{
  public static void main()
  {
    iservicecollection servicecollection = new servicecollection();
    configureservices(servicecollection);
    application application = new application(servicecollection);
    // run
    // ...
  }
  static private void configureservices(iservicecollection servicecollection)
  {
    iloggerfactory loggerfactory = new logging.loggerfactory();
    servicecollection.addinstance<iloggerfactory>(loggerfactory);
  }
}
public class application
{
  public iserviceprovider services { get; set; }
  public ilogger logger { get; set; }
    public application(iservicecollection servicecollection)
  {
    configureservices(servicecollection);
    services = servicecollection.buildserviceprovider();
    logger = services.getrequiredservice<iloggerfactory>()
            .createlogger<application>();
    logger.loginformation("application created successfully.");
  }
  public void makepayment(paymentdetails paymentdetails)
  {
    logger.loginformation(
      $"begin making a payment { paymentdetails }");
    ipaymentservice paymentservice =
      services.getrequiredservice<ipaymentservice>();
    // ...
  }
  private void configureservices(iservicecollection servicecollection)
  {
    servicecollection.addsingleton<ipaymentservice, paymentservice>();
  }
}
public class paymentservice: ipaymentservice
{
  public ilogger logger { get; }
  public paymentservice(iloggerfactory loggerfactory)
  {
    logger = loggerfactory?.createlogger<paymentservice>();
    if(logger == null)
    {
      throw new argumentnullexception(nameof(loggerfactory));
    }
    logger.loginformation("paymentservice created");
  }
}

从概念上讲，可以将 servicecollection 类型认为是名称/值对，其中名称是稍后将要检索的对象的类型（一般为接口），而值是实现接口的类型或用于检索该类型的算法（委托）。因此，在图 1 的 host.configure­services 方法中调用 addinstance 可注册 iloggerfactory 类型的任何请求，该类型返回在 configureservices 方法中创建的相同 loggerfactory 实例。因此，application 和 paymentservice 均可以检索 iloggerfactory，而无需了解实现和配置记录器的知识（或程序集/nuget 引用）。同样，application 提供 makepayment 方法，无需了解关于要使用的付款服务的知识。

请注意，servicecollection 不直接提供 getservice 或 getrequiredservice 方法。而是由 servicecollection.buildserviceprovider 方法返回的 iserviceprovider 提供这些方法。此外，仅由提供程序提供的服务是调用 buildserviceprovider 之前添加的服务。

microsoft.framework.dependencyinjection.abstractions 还包括称为 activatorutilities 的静态帮助程序类，该类提供了一些有用的方法，用于处理未使用 iserviceprovider（自定义的 objectfactory 委托）注册的构造函数参数，或者在想要创建默认实例的情况下，调用 getservice 时返回 null（请参阅 bit.ly/1wit4ka#activatorutilities）。

服务生存期

在图 1 中，我调用了 iservicecollection addinstance<tservice>(tservice implementationinstance) 扩展方法。instance 是 .net core di 附带的四个不同的 tservice 生存期选项之一。它规定不仅 getservice 的调用将返回 tservice 类型的对象，而且将返回使用 addinstance 注册的特定 implementationinstance 实例。换句话说，使用 addinstance 进行注册可以保存特定的 implementationinstance 实例，因此每次使用 addinstance 方法的 tservice 类型参数调用 getservice（或 getrequiredservice）时均可以返回该实例。

相反，iservicecollection addsingleton<tservice> 扩展方法没有实例参数，而是依赖于通过构造函数进行实例化的 tservice。默认的构造函数有效，microsoft.extensions.dependency­injection 也支持注册了参数的非默认构造函数。例如，你可以调用：

 

ipaymentservice paymentservice = services.getrequiredservice<ipaymentservice>()

而且，在实例化需要其构造函数中的 iloggingfactory 的 paymentservice 类时，di 将负责检索具体的 iloggingfactory 实例并利用该实例。

如果 tservice 类型中没有此类方法可用，则可以重载 addsingleton 扩展方法，该方法采用了 func<iserviceprovider, tservice> implementationfactory（用于实例化 tservice 的工厂方法）类型的委托。无论你是否提供工厂方法，服务收集实现都会确保将仅创建一个 tservice 类型的实例，从而确保存在单一实例。在第一次调用触发 tservice 实例的 getservice 后，在服务收集的生存期内将始终返回同一实例。

iservicecollection 还包括 addtransient(type servicetype, type implementationtype) 和 addtransient(type servicetype, func<iserviceprovider, tservice> implementationfactory) 扩展方法。这些方法类似于 addsingleton，不同的是每次调用这些方法时都会返回一个新实例，从而确保你始终拥有 tservice 类型的新实例。

最后，有几个 addscoped 类型的扩展方法。这些方法设计为在给定的上下文中返回同一实例，并且每当上下文（也称为作用域）更改时都会创建新实例。从概念上讲，asp.net core 的行为映射到作用域生存期。从本质上讲，新实例是针对每个 httpcontext 实例创建的，而且每当在相同的 httpcontext 内调用 getservice 时，都会返回完全相同的 tservice 实例。

总之，有四个生存期选项，用于从服务收集实现返回的对象： instance、singleton、transient 和 scoped。最后三个是在 servicelifetime 枚举中定义的 (bit.ly/1sftcag)。但是，缺少 instance，因为它是 scoped（在其中无法更改上下文）的特殊用例。

之前我提到过 servicecollection 在概念上就像一个名称/值对，它将 tservice 类型用于查找。servicecollection 类型的实际实现在 servicedescription 类中完成（请参阅 bit.ly/1sfodgu）。该类为实例化 tservice（即，servicetype (tservice)）、implementation­type 或 implementationfactory 委托以及 servicelifetime 所需的信息提供了一个容器。除了 servicedescriptor 构造函数，servicedescriptor 上还有许多静态工厂方法，可帮助实例化 servicedescriptor 本身。

无论使用哪种生存期注册 tservice，tservice 本身必须是一个引用类型，而不是值类型。每当你将类型参数用于 tservice（而不是作为参数传递 type）时，编译器都会使用泛型类约束进行验证。然而，编译器不会验证是否使用的是对象类型 tservice。你一定要避免这种情况，以及任何其他非独特的接口（或许如 icomparable）。原因是，如果你注册了对象类型的内容，无论你在 getservice 调用中指定哪种类型的 tservice，将始终返回注册为 tservice 类型的对象。

di 实现的依赖关系注入

asp.net 利用 di 的程度之深，事实上，你可以在 di 框架本身内实现 di。换句话说，你不限于使用在 microsoft.extensions.dependencyinjection 中发现的 di 机制的 servicecollection 实现。相反，只要你有实现 iservicecollection（在 microsoft.extensions.dependencyinjection.abstractions 中定义，请参阅 bit.ly/1skdm1z）或iserviceprovider（在 .net core lib 框架的 system 命名空间内定义）的类，你就可以替代自己的 di 框架或利用另外一个完善的 di 框架，其中包括 ninject（，经过数年的努力维护 @ianfdavis 呼之欲出）和 autofac ()。

浅谈 activatorutilities

microsoft.framework.dependencyinjection.abstractions 还包括静态帮助程序类，该类提供了一些有用的方法，用于处理未使用 iserviceprovider（自定义的 objectfactory 委托）注册的构造函数参数，或者在想要创建默认实例的情况下，调用 getservice 时返回 null。你可以找到一些在 mvc 框架和 signalr 库中使用此实用工具类的示例。在第一种情况下，存在一个带有 createinstance<t>(iserviceprovider provider, params object[] parameters) 签名的方法，允许你针对未注册的参数使用 di 框架将构造函数参数传入到注册的类型中。你可能还会有性能需求，lambda 函数需要生成已编译的 lambda 类型。返回 objectfactory 的 createfactory(type instancetype, type[] argumenttypes) 方法在这种情况下可能有用。第一个参数是用户寻求的类型，而第二个参数是所有的构造函数类型，以匹配你希望使用的第一个类型的构造函数。在其实现中，这些片段都精简到已编译的 lambda，多次调用后，性能会相当高。最后，getserviceorcreateinstance<t>(iserviceprovider provider) 方法提供了一个简单方式，用于提供可能已选择在其他地方注册的类型的默认实例。这在调用之前允许 di 的情况下尤为有用，但是，如果未发生这种情况，你会获得一个回退实现。

总结

与 .net core 日志记录和配置一样，.net core di 机制提供了一个相对简单的功能实现。虽然你不可能找到其他一些框架的更高级的 di 功能，但 .net core 版本是轻量级的，并且是一个很好的入门方式。此外（再如日志记录和配置），.net core 实现可以被一个更成熟的实现替代。因此，你可能会考虑利用 .net core di 框架作为一个“包装器”，通过它，将来你可以根据需要插入其他 di 框架。通过这种方式，你不必定义自己的“自定义”di 包装器，但可以利用 .net core 的包装器作为标准，任何客户端/应用程序都可以为标准的包装器插入自定义的实现。

关于 asp.net core 需要注意的是，它自始至终都在利用 di。这无疑是一个重大实践，在单元测试中尝试替代库的模拟实现时，如果你需要它，它会尤为重要。缺点是，并非简单的调用带有 new 运算符的构造函数，di 注册和 getservice 调用的复杂性是必要的。我不禁想知道，c# 语言是否可以简化这种复杂性，但是，基于目前的 c# 7.0 设计，要实现这一点并不容易。

 

原文：https://msdn.microsoft.com/zh-cn/magazine/mt707534.aspx