はじめに

MicrosoftLearnでBlazorを学習していると、題材としてDbContextというものが出てきて、今回おそらく初めて触りました。
使い方の注意点があったので、それをまとめます。

私は普段、C#でWindowsのデスクトップアプリを開発しています。
Webの技術を体系的に学び、しっかり活用した経験がなく用語の理解も怪しいので、超初歩的な内容になってます。

DbContextについて

DbContext は、Entity Framework Core (EF Core) の主要なクラスで、データベースとの接続、クエリの実行、データの追加・更新・削除など、いい感じにデータベースを扱えるようにしてくれるものみたいです。
大量に機能があったので、詳しくはこちら。

DbContextクラスを継承したクラスを定義することによって、アプリケーションのデータベースに特化した設定や操作を定義できます。

DbContextの注意点

DbContextは、同時に使用できるよう設計されていません。特に、サーバーアプリケーションのようにスコープが長く続く場合には、DIコンテナから直接DbContextを取得して使用するのは不適切です。

サーバーアプリではスコープが長く続くとは？

Blazorには、WebAssembly（クライアント側）とServer（サーバー側）の2つのホスティングモデルがあります。(こちらの記事にまとめています。)
Blazor Server では、ユーザーのUI操作がサーバー上で処理され、結果がリアルタイムでクライアントに反映されます。各ユーザーのセッションがサーバー上で維持されるため、スコープが長く続きやすいです。

(セッション ≒ スコープだと思ってます。サーバー側とブラウザ側の間の通信が生きている間のことを指しています。リロードしたり、別タブ、別ブラウザなど、通信の単位が異なると、別スコープ(セッション)になる認識です。)

たとえば、ユーザーがブラウザを閉じない限り、1つのセッションが数十分、数時間続くこともあります。この長時間のセッションの間に、同じDbContextインスタンスが再利用されると、複数のリクエストが同時にアクセスする可能性があり、競合やデータの不整合が発生するリスクが高まります。
1操作ごとにDbContextの生成と破棄をするのが、望ましいとされているそうです。

DbContextFactoryの利用

この問題を解決するためにDbContextFactoryを利用するのがよいです。
DbContextFactoryを使用すると、必要なときに新しいDbContextインスタンスを生成し、使用後すぐに破棄することができます。
これにより、スコープが長く続く環境でも安全にデータベースアクセスを行えます。

以下のように使います。
DbContextを継承したクラスを指定して、DbContextFactoryをDI登録します。

// Program.cs
builder.Services.AddDbContextFactory<MyDbContext>();

利用したい箇所にFactoryを注入します。@injectで可能です。
DbContextの利用箇所でFactoryから生成します。
使用後は必ず破棄するよう、usingで囲います。

// XXXConponent.razor
@inject IDbContextFactory<MyDbContext> DbContextFactory
@code {
    public async Task LoadDataAsync() {
        using var context = DbContextFactory.CreateDbContext();
        var data = await context.MyEntities.ToListAsync();
        // データ処理
    }
}

まとめ

使い方の注意点はわかりましたが、DbContextを理解して使いこなすのが大変そうですね、、、。

参考