【5min+】更好的選項實踐。.Net Core中的IOptions

系列介紹

【五分鐘的dotnet】是一個利用您的碎片化時間來學習和豐富.net知識的博文系列。它所包含了.net體系中可能會涉及到的方方面面,比如C#的小細節,AspnetCore,微服務中的.net知識等等。

通過本篇文章您將Get:

  • 不在AspNet CoreStartup.cs中完成mvc的選項配置(比如在其它地方為MVC添加過濾器等操作)
  • 了解Options的使用
  • 了解IOptions、IOptionsMonitor、IOptionsSnapshot的區別

時長為五分鐘以內,建議先投幣再上車觀看??

正文

.NET Core為咱們提供的默認依賴注入方式[Microsoft.Extensions.DependencyInjection]相對來說功能已經很完善了,雖然有一些功能沒有實現(比如在使用factory進行注冊時無法獲取type等),但并不影響我們令接口與實現進行分離。

某些情況下,您會發現,當我們的業務類被添加到依賴注入容器中時,該類構造函數中所依賴的其它類都得一同添加到容器(雖然有某些奇技淫巧可以規避,但是構造函數注入依舊是規范的手段)??墑?,我的一些依賴類為選型類型怎么辦呢?比如下面的代碼:

public class MyBusinessClass
{
    public MyBusinessClass(SomeOptions options)
    {
        if (options.ShouldOpenTCP)
            //do something.....

        if (options.ShouldLogIndo)
            // do something
    }
}

SomeOptions是一個典型的選項項類型,我們通過它公開的一些屬性來對項目進行配置。而當MyBusinessClass被注入到容器的時候,意味著SomeOptions也需要被注入。

對于這種選項類型,微軟給出了專門的處理手段:Microsoft.Extensions.Options包。我們只需要使用該包為IServiceCollection提供的擴展方法AddOptions<TOptions>()就可以完成注入選項:

services.AddOptions<SomeOptions>();

public class MyBusinessClass
{
    public MyBusinessClass(IOptions<SomeOptions> options)
    {
        SomeOptions value = options.Value;
    }
}

看起來這和上面的代碼好像區別也不是很大吧。都是把SomeOptions添加到容器中,那么第二種方法和第一種方法比起來有什么優點呢?微軟專門推出該方式難道只是為了“年底沖業績”?

x

非也非也?第二種方式其實用了更好的解耦思想來設計。假如咱們的SomeOptions需要在其它??櫓行薷腦趺窗?? 如果用第一種直接注入到容易的方案的話,這就十分的困難。而使用AddOptions<TOptions>的方式您就可以輕而易舉。

Microsoft.Extensions.Options提供了IConfigureOptionsIPostConfigureOptions這兩種類似于生命周期鉤子的接口,讓您能夠在讀取選項的時候,進行某些操作。

在AspNetCore中試一試

在AspnetCore中就有一個很明顯的選項:MvcOptions,該選項提供了咱們配置MVC項目的各種各樣的參數。

//Startup.cs

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers(options =>
    {
        options.Filters.Add(new MyFileter());
    });
}

上面代碼是我們在Startup.cs中配置MvcOptions最最常見的步驟,這里我用添加一個全局過濾器來舉例。

如果我不想在Startup.cs中添加這句代碼怎么辦呢? 比如我寫了一個第三方的庫,庫中包含了N個過濾器,我肯定沒有辦法要求用戶在使用該庫的時候將這N個過濾器一個一個的添加到options中。(這里只是假設,雖然可以使用特性的方式來完成同樣的過濾器功能

這個時候就可以拿出我們上面講的一大殺器:IConfigureOptions.

internal class MvcOptionsConfigure : IConfigureOptions<MvcOptions>
{
    public void Configure(MvcOptions options)
    {
        options.Filters.Add(new MyFileter());
    }
}

services.AddSingleton<IConfigureOptions<MvcOptions>, MvcOptionsConfigure>();

這樣就完成了關注點的分離,我們不需要一直死守著Startup.cs文件不放,也不需要讓用戶手動去配置。只要我們知道IServiceCollection就可以往里面添加我們自己的業務點。當然,Microsoft.Extensions.Options包還提供了另外的方式讓您可以完成IConfigureOptions的同樣操作,不過這些操作都是像語法糖一樣,實質上是相同的:

//和上面同樣的功能
services.Configure<MvcOptions>(Options =>
{
     options.Filters.Add(new MyFileter());
});

IOptions、IOptionsMonitor和IOptionsSnapshot

在上面其實我們已經見過了IOptions的尊容,我們可以通過注入IOptions<MyOptions>來獲取MyOptions實例。

但是!但是!但是?。。?! IOptions還有兩個兄弟IOptionsMonitorIOptionsSnapshot。光名字上長的就很像了,它們都還有類似于“Value”的屬性來獲取選項實例。

媽呀,那么它們到底有什么不同呢?什么時候該用老大,什么使用該用老二呢? 接下來,年度最佳找不同大戲即將開始………………

先來看看IOptionsIOptionsSnapshot吧,看看它們的接口定義:

/// <summary>
/// Used to access the value of <typeparamref name="TOptions"/> for the lifetime of a request.
/// </summary>
/// <typeparam name="TOptions">Options type.</typeparam>
public interface IOptionsSnapshot<out TOptions> : IOptions<TOptions> where TOptions : class, new()
{
    /// <summary>
    /// Returns a configured <typeparamref name="TOptions"/> instance with the given name.
    /// </summary>
    TOptions Get(string name);
}

我天,居然IOptionsSnapshot還繼承了IOptions,而且只是多了一個Get方法,那么是否這兩個類其實很相似呢?我們直接來看看源碼:

services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptions<>), typeof(OptionsManager<>)));
services.TryAdd(ServiceDescriptor.Scoped(typeof(IOptionsSnapshot<>), typeof(OptionsManager<>)));

納尼?這都還不是相似不相似的問題,這TM不是同一個實現嗎?只是接口類型不同而已,實現都是OptionsManager<>。 那為啥要搞兩個不同的接口。

等等(手動播放名偵探bgm),這倆生命周期咋不一樣? 一個是Singleton一個是Scoped。而再來看IOptionsSnapshot的說明:“Used to access the value of TOptions for the lifetime of a request.”(用于在請求的生存期內訪問選項的值)。

原來如此,這樣看來就很清晰了。它倆的區別其實就是依賴注入的生命周期不同而已,為單例的IOptions意味著,只要您注入之后以后獲取的都是同一個實例,而IOptionsSnapshot呢,作為Scoped級別,每再一個新的Scoped中獲取它一次,它就會請求一個新的實例。

所以來舉個例子,在AspNet Core中咱們某個選項的值是根據一個文件的某個值來的。剛開始文本的值是“A”,咱們在運行AspNet Core之后我們獲取IOptions<MyOptions>IOptionsSnapshot<MyOptions>,此時得到的MyOptions的該屬性的值都是"A"。但是假如我們更改了文本的值,改為“B”。如果在發起一個http請求去獲取MyOptions的結果,此時IOptions<MyOptions>依舊是“A”,而IOptionsSnapshot<MyOptions>則更改為了B。

原因很簡單,因為IOptions<MyOptions>是單例的,所以從程序一開始加載過一次之后,以后訪問它都是這個結果,而IOptionsSnapshot<MyOptions>是Scoped級別的,所以每一個新的Scoped時都會又去訪問文本文件獲取值,而一次Http請求就會開啟一次新的Scoped,所以此時結果就成為“B”。這個時候我們大概就能讀懂上面IOptionsSnapshot<>接口的解釋了:“用于在請求的生存期內訪問選項的值”。

三兄弟一下就干掉了倆,接下來看看最后一個好兄弟(毒瘤):IOptionsMonitor?;故侵苯涌此腦創肽兀?/p>

services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptionsMonitor<>), typeof(OptionsMonitor<>)));

納尼?單例? 那是不是意味著它也一樣,一旦啟動了之后還是保持原有的結果呢?先不急,看看它的接口定義再說:

/// <summary>
/// Used for notifications when <typeparamref name="TOptions"/> instances change.
/// </summary>
/// <typeparam name="TOptions">The options type.</typeparam>
public interface IOptionsMonitor<out TOptions>
{
    /// <summary>
    /// Returns the current <typeparamref name="TOptions"/> instance with the <see cref="Options.DefaultName"/>.
    /// </summary>
    TOptions CurrentValue { get; }

    /// <summary>
    /// Returns a configured <typeparamref name="TOptions"/> instance with the given name.
    /// </summary>
    TOptions Get(string name);

    /// <summary>
    /// Registers a listener to be called whenever a named <typeparamref name="TOptions"/> changes.
    /// </summary>
    /// <param name="listener">The action to be invoked when <typeparamref name="TOptions"/> has changed.</param>
    /// <returns>An <see cref="IDisposable"/> which should be disposed to stop listening for changes.</returns>
    IDisposable OnChange(Action<TOptions, string> listener);
}

可以看出它自己是一個單獨的接口,并不像其它倆兄弟是繼承關系。而且該接口居然有一個OnChange簽名?而且該方法需要一個Action<TOptions, string>的參數。

握草(繼續手動播放名偵探bgm),如果您有幸看過我的上一篇文章:《【5min+】 一個令牌走天下!.Net Core中的ChangeToken》,那么您可能一下就知道它扮演了什么樣的角色。(5min+系列居然是連續的.... ??)

再看看該接口的說明:"Used for notifications when TOptions instances change."(用于在選項實例更改時進行通知)。果然和我們猜的一模一樣,那么它的實現類里面一定有咱們上一篇文章中提到的:ChangeTokenIChangeToken等東西。

來吧,扒開它的具體實現,驗證咱們的猜想:

 public OptionsMonitor(IOptionsFactory<TOptions> factory, IEnumerable<IOptionsChangeTokenSource<TOptions>> sources, IOptionsMonitorCache<TOptions> cache)
{
    _factory = factory;
    _sources = sources;
    _cache = cache;

    foreach (var source in _sources)
    {
        var registration = ChangeToken.OnChange(
                () => source.GetChangeToken(),
                (name) => InvokeChanged(name),
                source.Name);

        _registrations.Add(registration);
    }
}

意料之中,也就是說IOptionsMonitor<>的注入級別雖然是單例,但是因為它具有IChangeToken的實現,所以它能夠在選項源改變的時候,“立馬對選項做出對應的改變”。而改變依賴于IOptionsChangeTokenSource這個令牌源,目前.net core對很多常用工具都實現了該令牌源,比如Logger,Configuration等。所以當我們某個選項依賴于IConfiguration(appsetting.json)的某一項時,當修改appsetting.json文件,該選項的值就能夠立馬得到更改。

所以來回過頭來看這三兄弟。它們的區別其實在于變更的時效性:

類型 說明 時效性
IOptions 一旦程序啟動,該選項的值就無法更改 無時效性可言
IOptionsSnapshot 當開啟一個新Scoped時,就會重新計算選項的值 相對比較低,依賴于合適開啟一個新的Scoped
IOptionsMonitor 依賴于IChangeToken,只要令牌源變更則立刻做出反應

假如把IOptionsMonitor<MyOptions>添加到上面IOptions<MyOptions>IOptionsSnapshot<MyOptions>的文件變更案例,如果在一次HTTP請求中,文件變更了兩次,那么IOptionsSnapshot<MyOptions>不會在第二次更改中同步更改,而IOptionsMonitor<MyOptions>則可以。

那么什么時候來使用什么樣的接口呢?相信這個時候,您的心里比我還要清楚。當您的選項只是負責一次性處理的時候,應用啟動了就不需要更改,那么考慮使用IOptions<MyOptions>,如果是對數據源的變更要求很嚴格,比如開啟了一個“BackgroundJob”在后臺運行,該job需要一個選項類型,而該類型依賴于配置文件,需要對配置文件更改時即刻做出改變,那么請考慮使用IOptionsMonitor<MyOptions>。

最后回過頭來看微軟官方文檔上關于“Options”的兩個點(ISP和關注點分離),您應該一下就能理解。
x

如果您有興趣的話可以跳轉至官方文檔進行閱讀:《ASP.NET Core 中的選項模式》

好啦,今天的車就開完了,如果您喜歡該系列文章可以點擊關注。??

最后,偷偷說一句:創作不易,點個推薦吧.....

x

我的博客即將同步至騰訊云+社區,邀請大家一同入駐:https://cloud.tencent.com/developer/support-plan?invite_code=1fam5s82ttu5f

posted @ 2020-03-27 18:14  句幽  閱讀(...)  評論(...編輯  收藏