BlazorのScopedとSingletonの違いとは？正しい使い分けを理解しよう｜ASP.NET×Blazor入門 8.2

8.2 Scoped vs Singleton の違い

Blazorアプリケーションで依存性注入（DI）を活用する際に重要なのが、「ライフタイムの違い」です。 特に Scoped と Singleton は、同じように「状態を共有する」ように見えて、 実は全く異なる挙動をします。

Singleton：アプリ全体で1つのインスタンス

AddSingleton<T>() で登録されたサービスは、アプリケーションが起動してから終了するまで、 ずっと同じインスタンスが使われ続けます。つまり、全ユーザー間で共通のインスタンスになります。

これは以下のような用途に適しています：

  • 設定値など、変更されない共通データ
  • ログ出力など、ステートを持たないユーティリティ

Scoped：ユーザー単位のインスタンス

一方、AddScoped<T>() で登録されたサービスは、ユーザーごとにインスタンスが分かれます。 特に Blazor Server アプリでは、ユーザーごとに独立した「回線（SignalR接続）」が張られ、それぞれにスコープが作られます。

Scopedが適しているケース：

  • ログイン中のユーザーの状態管理
  • セッションごとのデータの保持（例：一時的なフォーム入力）

注意：Blazor WASMではScopedは「疑似Scoped」

Blazor WebAssemblyでは、サーバーとの接続が存在しないため、Scopedは内部的にTransientと同等の動きになります。 つまり、呼び出しごとに新しいインスタンスが作られます。状態を保持したい場合は、Singletonの使用を検討する必要があります。

比較まとめ

ライフタイム インスタンスの範囲 用途の例
Singleton 全アプリで1つ 設定情報、ログユーティリティ
Scoped ユーザー単位（Blazor Server） ユーザーの状態、セッション管理
Transient 呼び出しごと 一時的な計算・処理

次のセクションでは、実際に 状態管理サービスをどう設計するか を見ていきます。 8.3「状態管理サービスの設計例」へと進んでみましょう。

2025-05-05
Blazor
Scoped
Singleton
DI
依存性注入
ライフタイム
状態管理

下田 昌平

開発に関するインプットをアウトプットしています。

Categories

Tags

Search Logs