在上面一章我們以實例演示的方式介紹了幾種讀取配置的幾種方式，其中涉及到三個重要的對象，它們分別是承載結構化配置信息的Configuration，提供原始配置源數據的ConfigurationProvider，以及作為“中間人”的ConfigurationBuilder。接下來我們將會對由這三個核心對象組成的配置模型進行詳細介紹，不過在此之前我們有必要來認識配置信息在不同載體中所體現出來的三種結構。

目錄
一、配置的三種結構
邏輯結構
原始結構
物理結構
結構轉換
二、Configuration
三、ConfigurationProvider
四、ConfigurationBuilder

一、配置的三種結構

相同的數據具有不同的表現和承載方式，同時體現出不同的數據結構。對于配置來說，它在消費過程中是以Configuration對象的形式來體現的，該對象邏輯上具有一個樹形化的層次結構。配置具有多種來源，可以是內存對象、物理文件或者數據庫，不同類型的數據源決定了不同的配置結構。我們將這兩種結構稱為邏輯結構和原始結構。在這兩種結構之間，配置還存在一種中間結構，我們姑且稱之為物理結構。

邏輯結構

配置的邏輯結構就是Configuration對象所體現的結構，說得更加準確一點應該是針對Configuration對象的API所體現的結構（因為不是所有的Configuration對象內部都封裝一組配置數據）。配置在邏輯上呈現為一種樹形結構，我們稱之為配置樹，組成這棵樹的某個節點就體現為一個Configuration對象。表現為鍵值對的原子配置項存儲于葉子節點中，而非葉子節點僅僅體現為一個配置節點的邏輯容器，自身不包含具體的配置數據。對于我們在第一節定義的FormatSettings來說，它對應的配置具有如右圖所示的邏輯結構。

原始結構

配置采用怎樣的原始結構取決于我們采用何種方式定義它。最常見的配置源體現為采用某個格式的文本文件，那么配置的原始結構則由文件的格式來決定。對于我們在第一節定義的FormatSettings類型，我們可以按照如下的形式以XML和JSON的格式來定義其配置。

XML:

1: <Format> 2: <DateTime> 3: <LongDatePattern>dddd, MMMM d, yyyy</LongDatePattern> 4: <LongTimePattern>h:mm:ss tt</LongTimePattern> 5: <ShortDatePattern>M/d/yyyy</ShortDatePattern> 6: <ShortTimePattern>h:mm tt</ShortTimePattern> 7: </DateTime> 8: <CurrencyDecimal> 9: <Digits>2</Digits> 10: <Symbol>$</Symbol> 11: </CurrencyDecimal> 12: </Format>

JSON:

1: { 2: "format": { 3: "dateTime": { 4: "longDatePattern" : "dddd, MMMM d, yyyy", 5: "longTimePattern" : "h:mm:ss tt", 6: "shortDatePattern" : "M/d/yyyy", 7: "shortTimePattern" : "h:mm tt" 8: }, 9: "currencyDecimal": { 10: "digits": "2", 11: "symbol": "$" 12: } 13: } 14: }

物理結構

配置模型的終極目的就是將配置從原始結構轉換成邏輯結構。不過在進行結構轉化的時候，它并不會直接將原始的配置數據轉換成一個Configuration對象，它們之間由一種被我稱為物理結構的中間結構作為過度。配置的物理結構體現為一個簡單的數據字典。同樣是針對FormatSettings這個類型，對應的配置將具有如下表所示的物理結構。

結構轉換

配置模型的終極目的在于將具有不同來源的配置轉換成Configuration對象，配置源和Configuration對象本身分別體現了配置的原始結構和邏輯結構，所以配置模型旨在實現配置數據從原始結構向邏輯結構的轉換。在具體轉換過程中，配置模型先利用與配置源相對應的ConfigurationProvider將配置數據從原始結構轉換成體現為數據字典的物理結構。當我們利用ConfigurationBuilder生成Configuration的時候，實際上將配置數據從物理結構轉換成邏輯結構。

二、Configuration

我們在上面以數據結構轉換的角度分析了Configuratin、ConfigurationProvider和ConfigurationBuilder這三個核心對象在配置模型中所起的作用，接下來讓我們來更加深入地認識它們。我們首先來介紹Configuration對象，本章不斷提及的Configuration泛指類型實現了IConfiguration接口的對象，該接口定義在“Microsoft.Extensions.Configuration”命名空間下，如果未作特別說明，本章涉及到的與配置相關的類型均定義在此命名空間下。

1: public interface IConfiguration 2: { 3: IEnumerable<IConfigurationSection> GetChildren(); 4: IConfigurationSection GetSection(string key); 5: IChangeToken GetReloadToken(); 6: 7: string this[string key] { get; set; } 8: }

配置具有樹形邏輯結構，一個Configuration對象表示配置樹的某個配置節點。對于組成整棵樹的所有配置節點來說，表示根節點的Configuration對象與表示其它配置節點的Configuration對象相比具有不同的特性，所以配置模型采用不同的接口來表示它們。具體來說，基于根節點的Configuration對象通過接口IConfigurationRoot表示，另一個接口IConfigurationSection則表示針對非空節點的Configuration對象，兩個接口都繼承IConfiguration。如右圖所示，一棵完整的配置樹由一個ConfigurationRoot對象和若干ConfigurationSection構成。

ConfigurationRoot

我們將所有實現了IConfigurationRoot接口的類型和其對象統稱為ConfigurationRoot。如下面的代碼片段所示，IConfigurationRoot僅僅包含一個唯一的方法Reload實現對配置數據的重新加載。一個ConfigurationRoot對象表示配置數的根節點，如果它被重新加載了，那么這顆配置樹承載的所有配置數據均被重新加載了。

1: public interface IConfigurationRoot : IConfiguration 2: { 3: void Reload(); 4: }

ConfigurationSection

我們將所有實現了IConfigurationSection接口的類型及其對象統稱為ConfigurationSection，一個ConfigurationSection對應著配置樹中某個非根配置節。IConfigurationSection具有如下三個屬性，只讀屬性Key用來唯一標識多個“同父”配置節，而另一個只讀屬性Path則表示從根節點到父節點的路徑，該路徑由ConfigurationSection的Key組成，并采用冒號作為分隔符。Path和Key的組合體現了當前配置節在整個配置樹中的位置。

1: public interface IConfigurationSection : IConfiguration 2: { 3: string Path { get; } 4: string Key { get; } 5: string Value { get; set; } 6: }

IConfigurationSection的Value屬性表示配置節的值，在大部分情況下，只有配置樹葉子結點對應的ConfigurationSection對象才具有值，非葉子節點對應的ConfigurationSection對象實際上僅僅表示一組隸屬于它的所有子配置節的邏輯容器，它們的Value一般返回Null。值得一體的是，這個Value屬性并不是只讀的，而是可讀可寫的。

在對ConfigurationRoot和ConfigurationSection具有基本了解情況下我們回過頭來看看定義在接口IConfiguration中的成員。它的GetChildren方法返回一組表示其子配置節的ConfigurationSection對象集合，另一個方法GetSection則根據指定的Key返回對應的ConfigurationSection對象。當GetSection方法執行的時候，指定的參數將會與當前ConfigurationSection的Path進行組合以確定目標ConfigurationSection所在的路徑，所以如果在調用該方法的時候指定一個相對于當前配置節的路徑，我們是可以得到子節點以下的某個配置節。

1: Dictionary<string, string> source = new Dictionary<string, string> 2: { 3: ["A:B:C"] = "ABC" 4: }; 5: IConfiguration root = new ConfigurationBuilder() 6: .Add(new MemoryConfigurationProvider(source)) 7: .Build(); 8:? 9: IConfigurationSection section1 = root.GetSection("A:B:C"); 10: IConfigurationSection section2 = root.GetSection("A:B").GetSection("C"); 11: IConfigurationSection section3 = root.GetSection("A").GetSection("B:C"); 12:? 13: Debug.Assert(section1.Value == section2.Value && section2.Value == section3.Value); 14: Debug.Assert(!ReferenceEquals(section1, section2) && !ReferenceEquals(section2, section3)); 15: Debug.Assert(null == root.GetSection(Guid.NewGuid().ToString()));

如上面的代碼片段所示，我們以不同的方式調用GetSection方法得到的都是路徑為“Format:DateTime:LongDatePattern”的ConfigurationSection。上面這段代碼還體現了另一個有趣的現象，雖然這三個ConfigurationSection對象均指向配置樹的同一個節點，但是它們卻并非同一個對象。換句話說，當我們調用GetSection方法的時候，不論配置樹種是否存在一個與指定路徑匹配的配置節，它總是會創建一個全新的ConfigurationSection對象。

IConfiguration還具有一個索引，我們可以指定子配置節的Key或者相對當前配置節的路徑得到對應配置節的值。當這個索引執行的時候，它會按照與GetSection方法完全一致的邏輯得到一個ConfigurationSection對象，并返回其Value屬性。如果配置樹中不具有匹配的配置節，該索引會返回Null而不會拋出異常。

三、ConfigurationProvider

為配置模型提供原始配置數據的ConfigurationProvider是對所有實現了IConfigurationProvider接口的所有類型及其對象的統稱。從配置數據結構轉換的角度來看，ConfigurationProvider的目的在于將配置數據從原始結構轉換成物理結構，由于配置數據的物理結構體現為一個簡單的二維數據字典，所以我們會發現定義在IConfigurationProvider接口中的方法大都體現為針對字典對象的相關操作。

1: public interface IConfigurationProvider 2: { 3: void Load(); 4:? 5: bool TryGet(string key, out string value); 6: void Set(string key, string value); 7: IEnumerable<string> GetChildKeys(IEnumerable<string> earlierKeys, string parentPath, string delimiter) 8: }

配置數據的加載通過調用ConfigurationProvider的Load方法來完成。我們可以調用TryGet方法獲取有指定的Key所標識的配置項的值。從數據持久化的角度來講，ConfigurationProvider基本上都是只讀的，也就是說ConfigurationProvider只負責從持久化資源中讀取配置數據，而不負責更新保存在持久化資源的配置數據，所以它提供的Set方法設置的配置數據一般只會保存在內存中。ConfigurationProvider的GetChildKeys方法用于獲取指定路徑對應配置節的所有子節點的Key。

每種不同類型的配置源都具有對應的ConfigurationProvider，它們對應的類型大都不會直接實現IConfigurationProvider接口，而是繼承另一個名為ConfigurationProvider的抽象類。這個抽象類的定義其實很簡單，從如下的代碼片段可以看出它僅僅是對一個IDictionary<string, string>對象的封裝，其Set和TryGetValue方法最終操作的都是這個字典對象。它實現了Load方法并將其定義成虛方法，具體的ConfigurationProvider可以通過重寫這個方法從相應的數據源中讀取配置數據并對這個字典對象進行初始化。

1: public abstract class ConfigurationProvider : IConfigurationProvider 2: { 3: protected IDictionary<string, string> Data { get; set; } 4:? 5: public IEnumerable<string> GetChildKeys(IEnumerable<string> earlierKeys, string parentPath, string delimiter) 6: { 7: //省略實現 8: } 9:? 10: public virtual void Load() 11: {} 12:? 13: public void Set(string key, string value) 14: { 15: this.Data[key] = value; 16: } 17:? 18: public bool TryGet(string key, out string value) 19: { 20: return this.Data.TryGetValue(key, out value); 21: } 22: //其他成員 23: }

接下來我們簡單介紹一下定義在這個抽象類中GetChildKeys方法的邏輯。采用基于路徑的Key讓數據字典在邏輯上具有了樹形化層次結構，而這個方法用于獲取將指定配置節作為父節點的所有配置節的Key。指定的父配置節通過參數parentPath表示的路徑來體現，另一個參數delimiter則表示路徑采用的分隔符。除此之外，這個方法還具有一個字符串集合類型的參數earlierKeys，它表示預先解析出來的Key，這個列表會包含在返回的結果中。

1: class Program 2: { 3: static void Main(string[] args) 4: { 5: Dictionary<string, string> source = new Dictionary<string, string> 6: { 7: ["A:B:C"] = "", 8: ["A:B:D"] = "", 9: ["A:E"] = "", 10: }; 11:? 12: MemoryConfigurationProvider provider = new MemoryConfigurationProvider(source); 13: Console.WriteLine("{0, -20}{1}", "Parent Path", "Child Keys"); 14: Console.WriteLine("------------------------------------------"); 15:? 16: Print("Null", provider.GetChildKeys(new string[] { "X", "Y", "Z" }, null, ":")); 17: Print("A", provider.GetChildKeys(new string[] { "x", "y", "z" }, "A", ":")); 18: Print("A:B", provider.GetChildKeys(new string[] { "X", "Y", "Z }, "A:B", ":")); 19: Print("A:B:C",provider.GetChildKeys(new string[] { "X", "Y", "Z }, "A:B:C", ":")); 20: } 21:? 22: static void Print(string parentPath, IEnumerable<string> keys) 23: { 24: Console.WriteLine("{0, -20}{1}", parentPath, string.Join(", ", keys.ToArray())); 25: } 26: }

為了讓讀者朋友們能夠更加直觀地理解GetChildKeys方法的邏輯，我們編寫了如上一段實例程序。我們創建了一個MemoryConfigurationProvider對象，由塔封裝的配置數據字段包含三個元素，它們對應的Key分別是“A：B：C”、“A：B：D”和“A：E”。我們調用它的GetChildKeys方法并將表示父節點的路徑分別指定為“A”、“A：B和“A：B：C”以獲取相應子節點的Key。除此之外，我們采用冒號（“：”）作為分隔符，并將earlierKeys指定為包含“X”、“Y”和“Z”三個元素的數組。這段程序執行之后會在控制臺上產生如下的輸出結果，我們從中可以看出一個細節，返回的結構并沒有將重復的Key剔除。

1: Parent Path Child Keys 2: ------------------------------------------ 3: Null X, Y, Z 4: A B, B, E, X, Y, Z: 5: A:B C, D, X, Y, Z 6: A:B:C X, Y, Z

四、ConfigurationBuilder

ConfigurationBuilder泛指所有實現了IConfigurationBuilder接口的類型及其對象，它在配置模型中的作用就是利用注冊的ConfigurationProvider提取轉換成數據字典的配置數據并創建對應的Configuration對象，具體來說創建的是一個體現配置樹的ConfigurationRoot對象。注冊到ConfigurationBuilder上的ConfigurationProvider體現為IConfigurationBuilder接口的Providers屬性，我們可以調用Add方法將ConfigurationProvider添加到這個集合中。

1: public interface IConfigurationBuilder 2: { 3: IEnumerable<IConfigurationProvider> Providers { get; } 4: Dictionary<string, object> Properties { get; } 5:? 6: IConfigurationBuilder Add(IConfigurationProvider provider); 7: IConfigurationRoot Build(); 8: }

除此之外，IConfigurationBuilder還具有一個字典類型的只讀屬性Properties，我們可以將任意自定義的屬性附加當一個ConfigurationBuilder對象上，并通過對應的Key得到這些屬性值。ConfigurationRoot的創建最終通過Build方法完成。

原生的配置模型中提供了一個實現IConfigurationBuilder接口的類型，那就是在我們之前演示的實例中多次使用的ConfigurationBuilder類，配置模型默認的配置生成機制體現在它實現的Build方法中。具體來說，實現在ConfigurationBuilder類中的Build方法返回對象的真實類型為ConfigurationRoot，該對象通過一個類型為ConfigurationSection對象表示非根配置節。右圖所示的UML展示了配置模型中以Configuration、ConfigurationProvider和ConfigurationBuilder為核心的相關接口/類型以及它們之前的關系。

ConfigurationRoot和ConfigurationSection這個兩個類型的定義體現配置模型默認采用怎樣的機制讀取配置數據，這是我們本節論述的重點內容。雖然配置模型最終提供的配置數據通過Configuration對象來體現，但是不論ConfigurationRoot還是ConfigurationSection對象，它們自身本沒有封裝任何的形式的配置數據，所有針對它們的數據讀寫操作最終都會轉移到相應的ConfigurationProvider上。由于Configuration對象僅僅體現為ConfigurationProvider的代理，所以由同一個ConfigurationBuilder創建的所有ConfigurationRoot對象都是等效的，下面的代碼片段體現了這樣的等效性。

1: IConfigurationBuilder builder = new ConfigurationBuilder().Add(new MemoryConfigurationProvider()); 2:? 3: IConfiguration config1 = builder.Build(); 4: IConfiguration config2 = builder.Build(); 5:? 6: config1["Foobar"] = "ABC"; 7: Debug.Assert(config2["Foobar"] == "ABC");

組成配置樹的ConfigurationRoot和ConfigurationSection不但自身封裝和配置數據，配置節父子關系的維護也并不直接通過對象之間的引用關系來維系。如右圖所示，對于一個表示配置樹中某個非根配置節的ConfigurationSection對象來說，它僅僅保留著對根節點的引用，后者是一個類型為ConfigurationRoot的對象。當我們調用ConfigurationSection方法獲取或者設置配置數據的時候，它會直接將調用請求轉發給表示配置樹根的ConfigurationRoot對象。

具體來說，當我們試圖通過某個ConfigurationSection對象得到對應配置節點的值時，該對象會將配置數據的讀取請求轉發給它所引用的表示數值樹根的ConfigurationRoot對象，同時將自身的路徑一并傳遞給后者。ConfigurationRoot最終利用ConfigurationProvider根據指定的路徑得到對應配置項的值，左圖揭示了這樣的流程。

在對實現在ConfigurationRoot和ConfigurationSection這兩個類中針對配置的讀寫機制有了大概的了解之后，我們從代碼實現的角度來進一步地來認識這兩個類型，在這之前我們需要先來認識一個名為ConfigurationPath的工具類。顧名思義，ConfigurationPath幫助我們實現針對配置樹路徑相關的計算，其中Combine方法將多個片段合并成一個完整的路徑，GetSectionKey方法會根據指定的路徑得到對應的Key，而GetParentPath則根據指定的路徑得到上一級的路徑。

1: public static class ConfigurationPath 2: { 3: public static string Combine(params string[] pathSegements) ; 4: public static string Combine(IEnumerable<string> pathSegements) ; 5: public static string GetSectionKey(string path) ; 6: public static string GetParentPath(string path) ; 7: }

ConfigurationRoot

ConfigurationRoot真實的實現邏輯基本上體現在如下所示的代碼片段中。一個ConfigurationRoot對象維護著一組提供原始配置數據的ConfigurationProvider對象，每一次對配置數據的讀寫操作最終都會轉移到它們頭上。當調用它的索引指定相應的Key獲取對應配置項的值時，我們會將這組ConfigurationProvider對象進行逆向排序，并將指定的Key作為參數依次調用每個ConfigurationProvider的TryGet方法直到該方法返回True，并將這個方法返回的值最為索引最終的返回值。當我們利用索引對指定配置項的值進行設置的時候，實際上會調用每個ConfigurationProvider的Set方法。

1: public class ConfigurationRoot: IConfigurationRoot 2: { 3: private IList<IConfigurationProvider> providers; 4:? 5: public ConfigurationRoot(IList<IConfigurationProvider> providers) 6: { 7: this.providers = providers; 8: providers.ForEach(provider => provider.Load()); 9: } 10:? 11: public string this[string key] 12: { 13: get 14: { 15: string value = null; 16: return providers.Reverse().Any(p => p.TryGet(key, out value)) 17: ? value: null; 18: } 19: set 20: { 21: providers.ForEach(provider => provider.Set(key, value)); 22: } 23: } 24:? 25: public IEnumerable<IConfigurationSection> GetChildren()=> this.GetChildren(null); 26:? 27: public IConfigurationSection GetSection(string key) => new ConfigurationSection(this, key); 28:? 29: public void Reload() => providers.ForEach(provider => provider.Load()); 30:? 31: internal IEnumerable<IConfigurationSection> GetChildrenCore(string path) 32: { 33: return providers.Aggregate(Enumerable.Empty<string>(), 34: (seed, source) => source.GetChildKeys(seed, path, ":")) 35: .Distinct() 36: .Select(key => GetSection(ConfigurationPath.Combine(path, key))); 37: } 38: //其它成員 39: }

ConfigurationRoot實現在索引中讀取配置的邏輯體現了配置模型一個重要的特性，那就是如果某個配置項的數據具有多個來源，那么最后添加到ConfigurationBuilder中的ConfigurationProvider具有更高的優先級，我們姑且將這個特性稱為ConfigurationProvider“后來居上”的原則。如果希望覆蓋應用現有的某個配置，我們只需要將提供新配置的ConfigurationProvider添加到ConfigurationBuilder之上即可。

我們定義了一個輔助方法GetChildrenCore來獲取某個配置節的所有子配置節，這個指定的配置節通過作為參數的路徑來表示。當這個方法執行之后，所有ConfigurationProvider的GetChildKeys方法會被調用以獲取所有子配置節的Key，我們利用它們生成表示配置節的ConfigurationSection對象。在實現的GetChildren方法中，我們會調用這個方法來獲取隸屬于自己的所有子配置節。而另一個GetSection方法中，我們直接返回根據指定路徑（對于表示根配置節來說，參數key表示配置節的路徑）創建的ConfigurationSection對象。

ConfigurationSection

在上面關于用于模擬ConfigurationRoot類型定義的代碼中我們知道最終表示非根配置節的ConfigurationSection對象是根據它的路徑和作為根配置節的ConfigurationRoot對象創建的。ConfigurationRoot將配置的讀寫操作遞交給相應的ConfigurationProvider來完成，而ConfigurationSection則將委托自己的根配置節來完成讀寫配置的操作，這樣的策略體現在如下所示的代碼中。

1: public class ConfigurationSection: IConfigurationSection 2: { 3: private ConfigurationRoot root; 4: private string key; 5:? 6: public string Key 7: { 8: get { return key ?? (key = ConfigurationPath.GetSectionKey(this.Path)); } 9: } 10: public string Path { get; private set; } 11: public string Value { get; set; } 12: public string this[string key] 13: { 14: get 15: { 16: return root[this.Path]; 17: } 18:? 19: set 20: { 21: root[this.Path] = Value; 22: } 23: } 24:? 25: public ConfigurationSection(ConfigurationRoot root, string path) 26: { 27: this.root = root; 28: this.Path = path; 29: } 30:? 31: public IConfigurationSection GetSection(string key) => root.GetSection(ConfigurationPath.Combine(this.Path, key)); 32: public IEnumerable<IConfigurationSection> GetChildren() => root.GetChildren(this.Path); 33: //其它成員 34: }

---

[1] ForEach是為了讓代碼盡量精練而為類型IEnumerable<T>定義的擴展方法，在后續章節中我們會經常使用到它。

?

ASP.NET Core的配置（1）：讀取配置信息
ASP.NET Core的配置（2）：配置模型詳解
ASP.NET Core的配置（3）： 將配置綁定為對象[上篇]
ASP.NET Core的配置（3）： 將配置綁定為對象[下篇]
ASP.NET Core的配置（4）：多樣性的配置源[上篇]
ASP.NET Core的配置（4）：多樣性的配置源[中篇]
ASP.NET Core的配置（4）：多樣性的配置源[下篇]
ASP.NET Core的配置（5）：配置的同步[上篇]
ASP.NET Core的配置（5）：配置的同步[下篇]

轉載于:https://www.cnblogs.com/artech/p/asp-net-core-config-02.html

總結

以上是生活随笔為你收集整理的ASP.NET Core的配置（2）：配置模型详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。