最通俗易懂的依赖注入之服务注册与注入

最新推荐文章于 2022-11-16 18:41:10 发布

dotNET跨平台

最新推荐文章于 2022-11-16 18:41:10 发布

阅读量607

点赞数 1

文章标签： java spring python 设计模式编程语言

原文链接：https://mp.weixin.qq.com/s?__biz=MzAwNTMxMzg1MA==&mid=2654089550&idx=5&sn=618aadba865025235008f6a917a3f1ac&chksm=80d8151bb7af9c0d173c03d616abb6ec88381652de0200d48a1de0f6ac59bdf810bfaad95671&scene=126&&sessionid=0

版权

推荐关注「码侠江湖」加星标，时刻不忘江湖事

这篇文章是 ASP.NET 6 依赖注入系列文章的第 4 篇，点击上方蓝字可以阅读整个系列。

在上一篇文章中，我们讨论了依赖注入的服务容器与服务作用域。

接下来，在这篇文章中，我们继续深入了解服务注册与注入相关的内容。

服务注册

现在，让我们回头看一看ServiceCollection服务集合类型。

我们现在已经知道，根容器是通过调用服务集合的BuildSerivceProvider扩展方法创建的。

服务集合ServiceCollection对象是一个存放服务注册信息的集合。

以下是它的部分源码，完整代码在这里。

public class ServiceCollection : IServiceCollection
{
    private readonly List<ServiceDescriptor> _descriptors = new List<ServiceDescriptor>();
    private bool _isReadOnly;

    public int Count => _descriptors.Count;

    public ServiceDescriptor this[int index]
    {
        get
        {
            return _descriptors[index];
        }
        set
        {
            CheckReadOnly();
            _descriptors[index] = value;
        }
    }

    // ...
}

通过这部分代码可以发现，ServiceCollection本质上是一个元素类型为ServiceDescriptor的集合。

ServiceDescriptor 是服务描述类，它描述的是某个注册服务的基本信息，其中包含了服务类型本身以及它的实现类型，还有生命周期模式。

服务注册的本质就是创建相应的服务描述对象，并将其添加到服务集合对象中的过程。

依赖注入系统就是利用服务描述信息，才能够提供我们所依赖的服务实例，并注入其中。

依赖注入系统就会根据指定的服务类型从服务集合中，找到相应的服务描述对象，并且根据它提供的类型信息，来创建服务实例。

构造函数注入

依赖注入系统在创建服务实例时会先调用它的构造函数。

如果构造函数有参数，那么传入构造函数的所有参数必须也必须先进行初始化。

所以，服务实现类的构造函数必须具备一个基本的条件，那就是服务容器能够提供构造函数所需的所有参数，这就是构造函数注入。

如果当我们的服务实现类有多个重载版本的构造函数时，那么依赖注入系统会如何进行选择呢？

比如下面这个示例：

public static class Sample
{
    public interface IAccount{ }
    public interface IMessage{ }
    public interface ITool{ }
    public interface ITest{ }

    public class Account: IAccount{}
    public class Message: IMessage{}
    public class Tool: ITool{}

    public class Test: ITest
    {
        public Test(IAccount account)
        {
            Console.WriteLine($"Ctor:Test(IAccount)");
        }

        public Test(IAccount account, IMessage message)
        {
            Console.WriteLine($"Ctor:Test(IAccount,IMessage)");
        }

        public Test(IAccount account, IMessage message, ITool tool)
        {
            Console.WriteLine($"Ctor:Test(IAccount,IMessage,ITool)");
        }
    }

    public static void Main()
    {
        var test = new ServiceCollection()
            .AddTransient<IAccount, Account>()
            .AddTransient<IMessage, Message>()
            .AddTransient<ITest, Test>()
            .BuildServiceProvider()
            .GetService<ITest>();
    }
}

在这个例子中，定义了 4 个服务接口IAccount IMessage ITool ITest以及它们的实现类。

其中Test类型中定义了 3 个构造函数，它们的每一个参数都是一个服务。

为了确定依赖注入系统，会选择哪个构造函数来创建服务实例，每个构造函数都会在控制台中输出自身的字符串标识。

Main 方法中创建了一个服务集合对象，并且注册了除ITool以外的其它 3 个服务接口。

那么当我们获取ITest的服务实例时，会发生什么情况呢？它会通过执行哪个构造函数创建实例呢？

我们可以尝试分析一下，对于定义在Test类中的 3 个构造函数来说，

由于我们只注册了IAccount和IMessage服务接口，所以服务容器只能够提供给前两个构造函数的所有参数，

而第三个构造函数只有一个ITool类型的参数，服务容器无法提供。

根据前面所说的基本条件「服务容器能够提供构造函数所需的所有参数」，此种情况下，也只有Test类型的前两个构造函数是符合条件的。

那么在所有符合条件的构造函数中，依赖注入系统又会如何选择呢？

这里用一个专业的说法来描述：「如果某个构造函数的参数类型集合，能够成为所有合法构造函数参数类型集合的超集，那么这个构造函数就会被依赖注入系统选择。」

简单来说，就是在所有符合条件的构造函数中，选择参数最多的那个。

如果按照这两个条件来分析的话，那么应该是第二个构造函数，以下执行结果证明了这一点。

接下来，我们对上面的示例改动一下，修改了Test类型的构造函数：

public class Test: ITest
{
    public Test(IAccount account, IMessage message)
    {
        Console.WriteLine($"Ctor:Test(IAccount)");
    }

    public Test(IMessage message, ITool tool)
    {
        Console.WriteLine($"Ctor:Test(IAccount,IMessage)");
    }
}

public static void Main()
{
    var test = new ServiceCollection()
        .AddTransient<IAccount, Account>()
        .AddTransient<IMessage, Message>()
        .AddTransient<ITool, Tool>()
        .AddTransient<ITest, Test>()
        .BuildServiceProvider()
        .GetService<ITest>();
}

我们只为Test类型定义了两个构造函数，它们都具有两个参数：