タグ: dependency-injection

シングルトンは DbContext を注入できませんが、IDbContextFactory<T> なら注入できます。AddDbContextFactory がファクトリを既定でシングルトンとして登録するからです。呼び出しごとにコンテキストを生成して破棄し、インスタンスは決して保持しないでください。

IValidateOptions<T> を実装し、DI に登録して ValidateOnStart をチェーンすれば、不正な appsettings.json は最初にそれに触れたリクエストではなくプロセスそのものを落とします。.NET 11 の Validate<TValidator>() オーバーロード、IAsyncValidateOptions<T> による非同期検証、そして ValidateOnStart が黙って何もしない 3 つのケースを解説します。

既定では IOptions<T> を使ってください。シングルトンが設定のリロードを見る必要がある場合は IOptionsMonitor<T> を、スコープ付きの利用側が 1 リクエストの間だけ安定した値を必要とする場合にのみ IOptionsSnapshot<T> を選びます。判断軸は設定の形ではなく、利用側のライフタイムです。

AddDbContext が実行されなかった、Build の後で実行された、またはコンテキストのコンストラクターが誤った DbContextOptions を受け取ると EF Core はこれをスローします。Build より前に登録し、DbContextOptions<YourContext> を使ってください。

AddKeyedSingleton/Scoped/Transient で同じサービス型の複数の実装をキーの下に登録し、[FromKeyedServices]、GetRequiredKeyedService、または KeyedService.AnyKey で解決します。キー付きとキーなしの登録は別々のテーブルであり、それがほぼ全員が引っかかる落とし穴です。

BackgroundService はシングルトンなので、DbContext のような scoped サービスを直接注入できません。IServiceScopeFactory を受け取り、CreateAsyncScope で作業単位ごとに scope を開き、その中で解決し、作業が終わったら破棄します。

MediatR 12-14 を削除し、IRequest ハンドラー、ISender、pipeline behavior、INotification をシンプルなサービスクラスとコンストラクター注入で置き換えるためのステップバイステップのチェックリスト。

新規コードには単純なサービスクラスがより良いデフォルトです。2025年7月のMediatRのライセンス変更が問題になるのは、Communityの500万ドルのしきい値を超えている場合か、RPL-1.5のcopyleftを拒否する場合だけです。pipeline behaviorsが不可欠なときはMediatRを残しましょう。

ASP.NET Core のスコープ検証は、シングルトンが scoped 依存をプロセス全体にわたってキャプチャしてしまう場合にこの例外を投げます。コンシューマーを scoped にするか、IServiceScopeFactory を注入して必要に応じてスコープを作成してください。

ASP.NET Core は、コンストラクターが登録されていない型、別のコンテナーに登録された型、またはホストのビルド後に追加された型を要求した場合にこの例外をスローします。3 つの具体的な修正でほぼすべてのケースをカバーします。