ASP.NET Core依賴注入系統學習教程：容器對構造函數選擇的策略
- 2022 年 8 月 15 日
- 筆記
- Asp.Net Core
.NET Core的依賴注入容器之所以能夠為應用程式提供服務實例，這都歸功於ServiceDescriptor對象提供的服務註冊資訊。另外，在ServiceDescriptor對象中，還為容器準備了3種提供服務實例的方式：
- 使用Func<IServiceProvider, object>類型的委託對象作為工廠進行提供；
- 直接使用實例化的對象進行提供；
- 根據服務的實現類型實例化進行提供；
如果容器選擇「根據服務的實現類型實例化進行提供」（上面的第3種方式）作為提供服務實例的方式，那麼容器就必須調用實現類型的構造函數才能創建相應類型的實例。在大部分的應用程式中，實現類型必然會對其他類型產生依賴，並且依賴的類型會存在多個，這就使實現類型為了初始化依賴的對象而定義多個構造函數。那麼對於這樣的情況而言，必然會產生一個問題：當容器發現實現類型中存在多個構造函數時，它會選擇哪一個構造函數來創建服務實例？
其實我們可以將容器對構造函數選擇的策略看作：使用兩個條件在多個構造函數中篩選的過程。最終同時滿足兩個條件，篩選出的唯一構造函數，就是容器用於創建服務實例的構造函數，這兩個條件如下：
- 構造函數中的參數類型，必須都進行了服務註冊；
- 構造函數中的參數列表，是所有構造函數的超集；
為了使讀者能夠更加深刻地理解策略中的兩個條件，下面我們會根據示例演示的方式進行講述。
示例背景
本示例將定義4個服務介面（IServiceA、IServiceB、IServiceC和IServiceD），以及實現這個4個介面的類型（ServiceA、ServiceB、ServiceC和ServiceD）。示例將選擇ServiceD類型作為切入點，所以容器將會在ServiceD類型的多個構造函數中選擇一個。其他的幾個類型將作為ServiceD類型的依賴項，並將它們通過ServiceD的構造函數對其初始化。
1 public interface IServiceA { }
2 public interface IServiceB { }
3 public interface IServiceC { }
4 public interface IServiceD { }
5
6 public class ServiceA: IServiceA { }
7 public class ServiceB : IServiceB { }
8 public class ServiceC : IServiceC { }
9 public class ServiceD : IServiceD
10 {
11 private IServiceA _serviceA;
12 private IServiceB _serviceB;
13 private IServiceC _serviceC;
14 private IServiceD _serviceD;
15 public ServiceD(IServiceA serviceA)
16 {
17 _serviceA = serviceA;
18 Console.WriteLine("選擇的是構造函數是：ServiceD(ServiceA serviceA)");
19 }
20
21 public ServiceD(IServiceA serviceA, IServiceB serviceB)
22 {
23 _serviceA = serviceA;
24 _serviceB = serviceB;
25 Console.WriteLine("選擇的是構造函數是：ServiceD(ServiceA serviceA, ServiceB serviceB)");
26 }
27 public ServiceD(IServiceA serviceA, IServiceB serviceB, IServiceC serviceC)
28 {
29 _serviceA = serviceA;
30 _serviceB = serviceB;
31 _serviceC = serviceC;
32 Console.WriteLine("選擇的是構造函數是：ServiceD(ServiceA serviceA, ServiceB serviceB, ServiceC serviceC)");
33 }
34
35 }
在控制台的演示程式中創建了一個ServiceCollection對象，並在其中添加針對IServiceA、IServiceB、IServiceD這3個服務介面的服務註冊，但未添加針對服務介面IServiceC的註冊。然後使用ServiceCollection對象的BuildServiceProvider方法構建容器對象，並通過容器對象獲取IServiceD的服務實例。
1 static void Main(string[] args)
2 {
3 var serviceCollextion = new ServiceCollection();
4 serviceCollextion.AddTransient<IServiceA,ServiceA>();
5 serviceCollextion.AddTransient<IServiceB, ServiceB>();
6 serviceCollextion.AddTransient<IServiceD, ServiceD>();
7
8 var provider = serviceCollextion.BuildServiceProvider();
9 provider.GetService<IServiceD>();
10
11 } // END Main（）
分析
在定義和編寫了示例中的程式碼後，在執行這個示常式序之前我們先使用策略中的第一個條件（構造函數中的參數類型，必須都進行了服務註冊），在結合和「服務註冊資訊」。然後通過圖例分析的方式來分析看看，容器會在ServiceD類型中篩選出哪些構造函數，使用第一個篩選條件的分析結果如下圖：
從上圖的分析內容可以看出，第三個構造函數被過濾掉了。這是因為第三個構造函參數列表的IServiceC類型並沒有進行服務註冊。另外，對於符合第一個篩選條件的構造函數，通常被稱為「候選構造函數」。在獲得第一個篩選條件的結果（候選構造函數列表）後，我們在使用第二個篩選條件（構造函數中的參數列表，是所有構造函數的超集）進行對其進行分析。
第二個篩選條件中的「超集」是篩選的核心，在這裡超集的意思就是：超集構造函數的參數列表，會包含所有構造函數的參數列表。每個候選構造函數的參數列表，都屬於超集構造函數參數列表的子集。
例如一個集合S2中的每個元素都在集合S1中，即便集合S1中可能存在S2中沒有的元素，但S1中的元素始終都會包含S2中所有元素，對於這樣的情況而言集合S1就是S2的一個超集。反過來，S2是S1的子集，S1是S2的超集。
有了對「超集」概念的理解，我們便可以看出在本示例的「候選構造函數」中，屬於超集的構造函數是：ServiceD(IServiceA serviceA, IServiceB serviceB)。此時，完成對「容器對構造函數選擇策略」的分析，我們可以判定：容器在面臨ServiceD類型多個構造函數時，會選擇使用其中第二個構造函數：ServiceD(IServiceA serviceA, IServiceB serviceB)，來實例化對象。
接下來我們通過運行本示例的演示程式，發現運行結果和我們使用「容器對構造函數選擇策略」分析的結果一致。
無超集
但是對於某些情況而言，如在使用第一個條件（構造函數所有的參數類型都進行了服務註冊）篩選出了符合條件的「候選構造函數」之後，沒有發現符合第二個條件(沒有超集)的構造函數會發生怎麼樣的現象？
接下來為了驗證這種情況會帶來什麼樣的現象，我們將程式碼示例進行如下的改動：
1 using Microsoft.Extensions.DependencyInjection;
2 using Microsoft.Extensions.DependencyInjection.Extensions;
3 using System;
4 using System.Collections.Generic;
5 using System.Diagnostics;
6 namespace ConsoleApp1
7 {
8 public interface IServiceA { }
9 public interface IServiceB { }
10 public interface IServiceC { }
11 public interface IServiceD { }
12
13 public class ServiceA: IServiceA { }
14 public class ServiceB : IServiceB { }
15 public class ServiceC : IServiceC { }
16 public class ServiceD : IServiceD
17 {
18 #region 欄位...
19 private IServiceA _serviceA;
20 private IServiceB _serviceB;
21 private IServiceC _serviceC;
22 private IServiceD _serviceD;
23 #endregion
24
25
26 public ServiceD(IServiceA serviceA, IServiceB serviceB)
27 {
28 _serviceA = serviceA;
29 _serviceB = serviceB;
30 Console.WriteLine("選擇的是構造函數是：ServiceD(ServiceA serviceA, ServiceB serviceB)");
31 }
32 public ServiceD(IServiceA serviceA,IServiceC serviceC)
33 {
34 _serviceA = serviceA;
35 _serviceC = serviceC;
36 Console.WriteLine("選擇的是構造函數是：ServiceD(ServiceA serviceA,ServiceC serviceC)");
37 }
38 }
39
40
41 internal class Program
42 {
43 static void Main(string[] args)
44 {
45 var serviceCollextion = new ServiceCollection();
46 serviceCollextion.AddTransient<IServiceA,ServiceA>();
47 serviceCollextion.AddTransient<IServiceB, ServiceB>();
48 serviceCollextion.AddTransient<IServiceC, ServiceC>();
49 serviceCollextion.AddTransient<IServiceD, ServiceD>();
50
51 var provider = serviceCollextion.BuildServiceProvider();
52 provider.GetService<IServiceD>();
53
54 } // END Main（）
55
56 }
57 }
對於上面改動的示例而言，ServiceD類型所有構造函數上的參數類型雖然都進行了服務註冊，即符合第一個篩選條件。但是並沒有一個構造函數的參數列表，能夠成為所有構造函數參數列表的超集，即不符合第二個篩選條件。接下來我們運行示常式序看看，當沒有超集的構造函數時會發生什麼樣的後果。
如上圖所示，在運行該示常式序後拋出了異常，其中的異常資訊表示：無法從兩個候選的構造函數中選擇一個最優的來創建服務實例。這個異常也意味著並沒有一個構造函數的參數列表，能夠成為所有構造函數參數列表的超集。
總結
對於本篇文章講解的主題——「容器對構造函數選擇的策略」，我個人認為其中講解的內容對於依賴注入框架而言是比較有實用性的。我們可以試想下，如果你沒有了解「容器對構造函數選擇的策略」，那麼你在為類型定義構造函數時並不會遵循策略，這很可能會導致你的應用程式中的類型沒有按預期方式實例化，或者出現無法實例化服務的異常現象。
所以為了穩妥的使用依賴注入框架，我們必須遵循「容器對構造函數選擇的策略」，以此保證了應用程式所依賴的類型進行了服務註冊，並且保證容器在面臨多個構造函數選擇時能夠選出對應的「超集」。
