dependency-injection

コードが、破棄済みの DI スコープまたはルートプロバイダーからサービスを解決しています。IServiceProvider の代わりに IServiceScopeFactory を保持し、処理が実行される場所で新しいスコープを作成してください。

AddDbContextPool は DI スコープごとに 1 つのスコープ付き DbContext を渡すため、2 つのクエリを同時に実行できません。AddDbContextFactory と AddPooledDbContextFactory は呼び出しごとにコンテキストを返すので、並列クエリに向いています。EF Core 11 RC 1 での計測では、プール付きファクトリはコンテキストを 342 ns、40 B で作成しますが、プールなしでは 17 us、44 KB かかります。

Aspire 13.5.4 より前は、AddKafka リソースに対する AppHost のヘルスチェックが実行のたびに新しい Confluent の producer を作成し、誰も破棄しませんでした。そのためポーリングスレッドが積み上がり、AppHost が CPU を消費していました。この修正と、その背後にある HealthCheckRegistration.Factory の落とし穴は、独自のヘルスチェックにも当てはまります。

シングルトンは 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 をシンプルなサービスクラスとコンストラクター注入で置き換えるためのステップバイステップのチェックリスト。