ASP.NET Core的配置(2):配置模型詳解

来源:http://www.cnblogs.com/artech/archive/2016/04/19/asp-net-core-config-02.html
-Advertisement-
Play Games

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


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

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

一、配置的三種結構

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

邏輯結構

1配置的邏輯結構就是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: }

物理結構

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

結構轉換

transfer配置模型的終極目的在於將具有不同來源的配置轉換成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: }

3配置具有樹形邏輯結構,一個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表示的路徑

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 異常處理彙總-開發工具 http://www.cnblogs.com/dunitian/p/4522988.html ...
  • 項目前景 由於之前的列印是客戶端程式,也就是winform做的,現在需要改版成網頁版,其他功能都能夠很好的實現,就是在列印上遇到一些難點。由於第一次做列印功能,剛開始照搬winform中調用word文檔實現列印,在本地運行時都很正常,可是發佈到IIS之後,怎麼也實現不了,經過研究學習,發現客戶端不可 ...
  • 最近抽空看了一下ASP.NET MVC的部分源碼,順帶寫篇文章做個筆記以便日後查看。 在UrlRoutingModule模塊中,將請求處理程式映射到了MvcHandler中,因此,說起Controller的激活,首先要從MvcHandler入手,MvcHandler實現了三個介面:IHttpAsyn ...
  • 一. css 2.x code 1. 文字換行 1./*強制不換行*/ 2.white-space:nowrap; 3./*自動換行*/ 4.word-wrap: break-word; 5.word-break: normal; 6./*強制英文單詞斷行*/ 7.word-break:break- ...
  • ...
  • 一:準備工作 APPcmd.exe 位於 C:\Windows\System32\inetsrv 目錄 使用 Cd c:\Windows\System32\inetsrv 切換到該目錄 二:命令操作簡介 IIS 命令行管理工具基本格式: APPCMD (命令) (對象類型) <標識符> </參數1: ...
  • 本文內容 引入 ASP.NET 頁生命周期概述 常規頁生命周期階段 生命周期事件 其他頁生命周期註意事項 數據綁定控制項的數據綁定事件 引入 工作之初,我用 VS 開發 Web 應用程式,最常用的頁面事件是 Page_Load 和 Page_Init,它們處於不同的頁面生命期。但漸漸地,這兩個事件已經 ...
  • 很久以前,我們就有Snoop這樣的工具實時修改、查看正在運行的WPF程式,那時候調個樣式,修改個模板,相當滋潤。隨著歷史的車輪陷進WP的泥潭中,無論WP7的Silverlight還是WP8.1的runtime,偶們都不能方便快捷的查看APP的可視化樹(Visual Tree)了,嗚呼哉,是可忍孰不可 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...