.NETの依存性注入の慣習: ライフタイム、スコープ、captive dependencyの罠

概要

.NETのドキュメントは組み込みのコンテナを次のように説明している: サービスは起動時にIServiceCollectionに追加され(AddTransient、AddScoped、AddSingleton、またはキー付きのバリエーション)、BuildServiceProviderやジェネリックホストがIServiceProviderを生成し、利用側は公開コンストラクタを通じて依存を受け取る。transientなサービスは要求されるたびに生成される。scopedなサービスはスコープごとに1回生成され、ASP.NET Coreではこれがリクエストに相当する。singletonはコンテナの生存期間中に1回だけ生成される。コンテナは自身が生成したものを破棄する: transientとscopedのインスタンスはスコープの終わりに、singletonはシャットダウン時に破棄される。ある型が複数のコンストラクタを持つ場合、DIで解決可能なパラメータが最も多いものが選ばれ、あいまいな場合は例外が送出される。

重要な理由

Spring(デフォルトでsingleton)出身のエンジニアや、コンテナを持たないフレームワークの出身者は、すべてをsingletonとして登録したり、サービスを手動で解決したりしがちである。ガイドラインのページは、そこから生じるバグをcaptive dependencyと呼んでいる。寿命の長いサービスが寿命の短いサービスを保持してしまうことで、たとえば「リクエストごと」のはずのDbContextがsingletonに捕まってしまうと、すべてのリクエストでひそかに共有されてしまう。ライフタイムのページは、scopedなサービスをコンストラクタ注入やIServiceProvider経由でsingletonから解決してはならないと述べており、文書化されている修正方法はIServiceScopeFactoryで明示的にスコープを作成することである。

適用方法

• ステートレスなサービスはデフォルトでtransientに、リクエストごとの状態(DbContext、unit of work)はscopedに、共有され、スレッドセーフで、生成コストの高い状態だけをsingletonにする。ガイドラインはsingletonがスレッドセーフでなければならないと述べ、結合とメモリについて警告している。
• コンストラクタではインターフェースに依存し、コンストラクタの中身は代入以上の処理を持たないようにする。
• 注入されたサービスに対してDisposeを呼んではならず、ルートプロバイダーから解決される可能性のあるIDisposableな型をtransientとして登録してもいけない。ガイドラインは、そうしたインスタンスはコンテナが破棄されるまで保持され続けると述べている。
• サービスを構成している最中にBuildServiceProviderを呼んではならず、GetServiceをサービスロケーターとして使ってもいけない。どちらもアンチパターンとして挙げられている。
• スコープの検証は有効にしておく: 開発用ホストは、scopedなサービスがルートから解決されたり、singletonに注入されたりしていないかをチェックしており、BuildServiceProviderのvalidateScopes: trueも他の場所で同じことを行う。
• ホストされたサービスやバックグラウンドサービスではIServiceScopeFactoryを注入し、作業単位ごとにスコープを作成する。

落とし穴

プロバイダーへの静的アクセス(ApplicationServicesをどこかにキャプチャすること)は避けるべきものとして挙げられている。ガイドラインは、静的なオブジェクトアクセスと混在させるとDIの利点が失われると述べている。設定やユーザーデータをoptionsパターンを使わずコンテナに保存してしまうこと。キー付きサービスにはパラメータに[FromKeyedServices("key")]が必要になる。同じサービスを2回登録してしまうのは合法だが見落としやすい。