.NET - オプションパターンでアプリケーション構成を型付きで取得するが、一部だけ動的に読み取りたい

オプションパターン

C# 等における .NET アプリケーション開発における話題。

.NET アプリケーション開発においては、appsettings.json やコマンドライン引数、はたまた環境変数などから指定される "設定情報" (アプリケーション構成) を取得するカラクリのひとつとして、"オプション パターン" という方法が用意されている。

例えば一般的な構成の ASP.NET Core Web アプリケーションの場合、 appsettings.json に以下の様に設定情報を書いておいたとして、

"MainWeapon": {

"Type": "Laser",

"Params" : {

"MaxLengthPixel": 120

}

}

C# であれば次のようなクラスを実装しておき、

public class MainWeaponOptions {

public string Type { get; set; } = "";

public ParamsForLaser Params { get; set; } = new();

}

public class ParamsForLaser {

public int MaxLengthPixel { get; set; }

}

これをアプリケーションの初期化時・サービス構成時に、以下のように DI に登録しておくと、

builder.Services.Configure<MainWeaponOptions>(

builder.Configuration.GetSection("MainWeapon")

);

この MainWeapon 構成情報を必要とする箇所で、DI から IOptions<T> という形で、appsettings.json に設定された内容を、型付きで取得・参照することができる。

(下記は同じく DI に登録した Foo クラスにて、コンストラクタへの注入にて、このMainWeapon 構成情報を入手する例)

public Foo(IOptions<MainWeaponOptions> mainWeaponOptions) {

// mainWeaponOptions.Vlaue.Type -> "Laser"

// mainWeaponOptions.Vlaue.Params.MaxLengthPixel -> 120

...

詳細は以下を参照されたし。

問題発生!

さてところで、このようにオプションパターンを活用して型安全にアプリケーション構成情報を入手していたのだが、後日、この MainWeapon 構成を拡張することになった。

例えば、以下のように、MainWeapon の Type として、"Laser" のみならず、"Ripple Laser" も指定可能とすることになったのだが...

"MainWeapon": {

"Type": "Ripple Laser", // <- "Laser" 以外も指定可能に!

"Params" : {

...

しかし、Type = "Ripple Laser" の場合、続く構成情報である "Params" セクションに設定したい内容が、Type = Laser の場合と大幅に異なることとなったのだ。

"MainWeapon": {

"Type": "Ripple Laser",

"Params" : {

"MaxRippleWidthPixel": 300,

"MaxBarrets": 4

}

このような場合、先に実装した MainWeaponOptions クラスに構成情報をバインドして参照することは不可能になってしまう。

つまり、前述の実装のままでは、MainWeaponOptions.Params プロパティの型は ParamsForLaser クラスであり、ParamsForLaser クラスには上記のような Type="Ripple Laser" の場合の Params 構成の内容をバインドできないからだ。

さてどうしたものか。

案1. ぜんぶ ParamsForLaser クラスにぶっこむ

ひとつには、愚直に、ParamsForLaser クラスのプロパティに、あり得る構成項目をすべて定義しておく方法が思いついた。

// MainWeaponOptions クラスは先の実装と変わらず。

public class MainWeaponOptions {

public string Type { get; set; } = "";

public ParamsForLaser Params { get; set; } = new();

}

public class ParamsForLaser {

// 以下は Type=Laser のときのみ参照される

public int MaxLengthPixel { get; set; }

// 以下は Type=Ripple Laser のときのみ参照される

public int MaxRippleWidthPixel { get; set; }

public int MaxBarrets { get; set; }

}

この方法、個人的には、何とも言えない気持ち悪さが残るのだが、まぁ、こんなものかもしれない。

案2. Params は個別のオプションオブジェクトとして参照する

次に考えたのは、MainWeaponOptions クラスのプロパティとして Params を参照するのではなく、Params は Params で独立したオプション型を定義しよう、という案だ。

まずは MainWeaponOptions クラスからは Params プロパティを撤去。

public class MainWeaponOptions {

public string Type { get; set; } = "";

}

で、ParamsForLaser クラスはそのままでよいとして、新たに ParamsForRippleLaser クラスを新設し、前述の構成情報をバインドできるプロパティを設ける。

public class ParamsForRippleLaser {

public int MaxRippleWidthPixel { get; set; }

public int MaxBarrets { get; set; }

}

その上で、DI にはこれらオプション型を個別に登録していく。

builder.Services.Configure<MainWeaponOptions>(

builder.Configuration.GetSection("MainWeapon")

);

builder.Services.Configure<ParamsForLaser>(

builder.Configuration.GetSection("MainWeapon:Params")

);

builder.Services.Configure<ParamsForRippleLaser>(

builder.Configuration.GetSection("MainWeapon:Params")

);

このようにしておいて、あとは、MainWeaponOptions の Type プロパティ値に応じて、必要な Params オプション型を実行時に動的に取得することができる。

public Foo(

IOptions<MainWeaponOptions> mainWeaponOptions,

IServiceProvider services

) {

if (mainWeaponOptions.Vlaue.Type == "Laser") {

var paramsOptions = service.GetRequiredService<IOptions<ParamsForLaser>>();

}

else if (mainWeaponOptions.Vlaue.Type == "Ripple Laser") {

var paramsOptions = service.GetRequiredService<IOptions<ParamsForRippleLaser>>();

}

...

実際には上記のような動的判定・動的オプション取得のコードは書かず、そもそも MainWeapon の Type に応じて利用する MainWeapon サービスインスタンスを取得仕分けるような気がする。

つまりは、実際のところは下記のようなコードになると思われる。

// Laser サービスクラスでは ParamsForLaser オプションを DI からもらい...

public class Laser : IMainWeapon {

public Laser(IOptions<ParamsForLaser> paramsOptions) {

...

}

// RippleLaser サービスクラスでは ParamsForRippleLaser オプションを DI からもらう。

...public class RippleLaser : IMainWeapon {

public RippleLaser(IOptions<ParamsForRippleLaser> paramsOptions) {

...

}

// 利用する側は、MainWeapon.Type に応じて利用する MainWeapon サービスを取得し分ける

public class Foo {

public Foo(

IOptions<MainWeaponOptions> mainWeaponOptions,

IServiceProvider services)

{

var mainWeaponType = mainWeaponOptions.Value.Type swtch {

"Laser" => typeof(Laser),

"Ripple Laser" => typeof(RippleLaser),

_=> throw new Exception();

};

var mainWeapon = services.GetRequiredService(mainWeaponType) as IMainWeapon;

上記コードは説明のために、利用者である Foo クラスのコンストラクタでごちゃごちゃ実装するコードにした。
現実的には DI に IMainWeapon サービスを登録し、その際、そのファクトリー関数内で上記のような仕分けコードを実装することになろう。

(で、上記例 Foo クラスではコンストラクタで IMainWeapon サービスを受け取るだけになる。)

DI 登録のコードが若干煩雑な印象もあるが、前述のような実際の実装シナリオを想定すると、個人的には、この方式がけっこう妥当な感じがしている。

案3. Params は辞書 (Dictionary<string,string>) で取得

別の案として、Params プロパティの型を、辞書 (Dictionary<string,string>) にしてしまう、という方法が思いついた。

すなわち、下記のように実装するわけである。

public class MainWeaponOptions {

public string Type { get; set; } = "";

public Dictionary<string, string> Params { get; set; } = new();

}

こうすると、appsettings.json 中の Params セクションの内容は、辞書として Params プロパティに格納される。

public Foo(IOptions<MainWeaponOptions> mainWeaponOptions) {

// mainWeaponOptions.Vlaue.Params["MaxLengthPixel"] -> "120"

...

これはこれで、MainWeaponOptions にキレイにまとまり、MainWeaponOptions のプロパティ経由で Params を参照できるので、直感的でわかりやすい感じはする。

しかしながら、辞書なので、Params 中の各項目を文字列でキー指定して参照することになるため、かつまた、どうやら値はすべて文字列型となるようなので、型安全性が失われてしまうのが嫌なところである。
(つまり、項目名のタイポをやらかしそうであるとか、値が数値なら int.Parse などで変換が必要になる、など)

個人的には採用は躊躇する案である。

案4. オプションパターンを使わず IConfiguraion から直接取得

最後の案としては、Params 構成セクションに限ってはそもそもオプションパターンを使わず、IConfiguration サービス経由で、直接、目的の Params 項目を参照する、という方式だ。

public Foo(

IOptions<MainWeaponOptions> mainWeaponOptions,

IConfiguraion config

) {

if (mainWeaponOptions.Vlaue.Type == "Laser") {

var maxLength = config.GetValue<int>("MainWeapon:Params:MaxLengthPixel");

}

else if (mainWeaponOptions.Vlaue.Type == "Ripple Laser") {

var maxRippleWidth = config.GetValue<int>("MainWeapon:Params:MaxRippleWidthPixel");

}

...

しかしこの IConfiguraion 経由で直接参照する方式は、構成情報中のセクション位置 ("MainWeapon:Params:MaxLengthPixel" のような) がそこかしこに散在してしまうので、わざわざこのような脆弱な実装を採用するメリットはまったく感じられない。

これなら案3の辞書方式のほうがよっぽど手軽でマシであるように思われる。

いちおう、こういう方法もあるな、と思いついたのでここに記した次第。

まとめ

以上、オプションパターンを採用しつつ、構成情報の一部分が実行時に決まるようなケースについて、どのように対処するか、思いついたアイディアを4案、書き連ねてみた。

案 1 のすべてのあり得る構成項目をぶっこむ案は、正直なところ、個人的には気持ち悪く、あまり近寄りたくない案である。
しかし要件や実装者の好みによってはアリなのかもしれない。

個人的なイチオシは、案 2 の当該構成情報部分のオプション型を独立したオプションとして DI に登録しまくる案である。

あと、急いでいるときは、とりあえず案3の辞書方式でお茶を濁すのも、まぁ、アリかな、と感じている。
タイポなどの心配はあるが (そしてマーフィーの法則のとおり、これが原因で事故る日が絶対くるはずw)、しかし案外、コードの可読性や全体的な見通しは悪くないと思う。

案 4 は、いちおう書いては見たものの、他の案のほうがよっぽどマシなので、まったくお勧め出来ない。

他にも何か別の実装方法などあれば、コメント欄、ないしは Twitter 等で言及頂ければと思う。