在上面一章我們以實例演示的方式介紹了幾種讀取配置的幾種方式,其中涉及到三個重要的對象,它們分別是承載結構化配置信息的Configuration,提供原始配置源數據的ConfigurationProvider,以及作為“中間人”的ConfigurationBuilder。接下來我們將會對由這三個核心對... ...
在上面一章我們以實例演示的方式介紹了幾種讀取配置的幾種方式,其中涉及到三個重要的對象,它們分別是承載結構化配置信息的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表示的路徑