次の方法で共有


ステート管理

ヒント

このコンテンツは、Azure 用の ASP NET Web Forms 開発者向けの電子ブック Blazor からの抜粋です。 .NET Docs またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できます。

Blazor-for-ASP-NET-Web-Forms-Developers 電子書籍の表紙サムネイル。

状態管理は、ViewState、セッション状態、アプリケーションの状態、ポストバック機能を通じて容易になる Web フォーム アプリケーションの主要な概念です。 フレームワークのこれらのステートフル機能は、アプリケーションに必要な状態管理を非表示にし、アプリケーション開発者が機能の提供に集中できるようにするのに役立ちました。 ASP.NET Core と Blazor では、これらの機能の一部が再配置され、一部が完全に削除されました。 この章では、Blazor の新機能を使用して状態を維持し、同じ機能を提供する方法について説明します。

ViewState を使用した状態管理の要求

Web フォーム アプリケーションで状態管理について説明すると、多くの開発者はすぐに ViewState について考えます。 Web フォームでは、ViewState は、大きなエンコードされたテキスト ブロックをブラウザーに送信することで、HTTP 要求間のコンテンツの状態を管理します。 ViewState フィールドは、多数の要素を含むページのコンテンツに圧倒される可能性があり、サイズが数メガバイトに拡張される可能性があります。

Blazor Server では、アプリはサーバーとの継続的な接続を維持します。 接続がアクティブと 見なされている間、回線と呼ばれるアプリの状態はサーバー メモリに保持されます。 状態は、ユーザーがアプリまたはアプリ内の特定のページから離れた場合にのみ破棄されます。 アクティブ コンポーネントのすべてのメンバーは、サーバーとの対話の間で使用できます。

この機能にはいくつかの利点があります。

  • コンポーネントの状態は簡単に使用でき、対話間で再構築することはできません。
  • 状態はブラウザーに送信されません。

ただし、メモリ内コンポーネントの状態永続化には、次のような欠点があります。

  • 要求の間にサーバーが再起動すると、状態が失われます。
  • アプリケーション Web サーバーの負荷分散ソリューションには、同じブラウザーからのすべての要求が確実に同じサーバーに返されるように、スティッキー セッションを含める必要があります。 要求が別のサーバーに送信されると、状態は失われます。
  • サーバー上のコンポーネントの状態が永続化すると、Web サーバーでメモリ不足が発生する可能性があります。

上記の理由から、サーバー上のメモリ内に存在するコンポーネントの状態だけに依存しないでください。 アプリケーションには、要求間のデータ用のバッキング データ ストアも含める必要があります。 この戦略の簡単な例を次に示します。

  • ショッピング カート アプリケーションで、データベース レコード内のカートに追加された新しい項目の内容を保持します。 サーバー上の状態が失われた場合は、データベース レコードから再構成できます。
  • マルチパート Web フォームでは、ユーザーはアプリケーションが各要求間の値を記憶することを期待します。 ユーザーの各投稿の間でデータ ストアにデータを書き込み、マルチパート フォームが完了したときに、そのデータをフェッチして最終的なフォーム応答構造にまとめられるようにします。

Blazor アプリでの状態の管理の詳細については、 ASP.NET Core Blazor 状態管理に関するページを参照してください。

セッションで状態を維持する

Web フォーム開発者は、 Microsoft.AspNetCore.Http.ISession ディクショナリ オブジェクトを使用して、現在動作しているユーザーに関する情報を保持できます。 文字列キーを持つオブジェクトを Sessionに簡単に追加できます。そのオブジェクトは、ユーザーがアプリケーションとやり取りする際に後で使用できるようになります。 HTTP との対話の管理を排除するために、 Session オブジェクトを使用すると、状態を簡単に維持できます。

.NET Framework Session オブジェクトのシグネチャは、ASP.NET Core Session オブジェクトと同じではありません。 新しいセッション状態機能を移行して使用することを決定する前に、 新しい ASP.NET Core セッションのドキュメント を検討してください。

セッションは ASP.NET Core および Blazor Server で使用できますが、データ リポジトリにデータを適切に格納する場合は使用しないことをお勧めします。 プライバシーに関する懸念により、訪問者がアプリケーションでの HTTP Cookie の使用を拒否した場合も、セッション状態は機能しません。

ASP.NET コアとセッションの状態の構成は、ASP.NET Core の記事のセッションと状態の管理で利用できます。

アプリケーションの状態

Web フォーム フレームワークの Application オブジェクトは、アプリケーション スコープの構成と状態を操作するための大規模なクロスリクエスト リポジトリを提供します。 アプリケーションの状態は、要求を行うユーザーに関係なく、すべての要求によって参照されるさまざまなアプリケーション構成プロパティを格納するのに理想的な場所でした。 Application オブジェクトの問題は、複数のサーバー間でデータが保持されなかったという点です。 再起動の間にアプリケーション オブジェクトの状態が失われました。

Sessionと同様に、複数のサーバー インスタンスからアクセスできる永続的なバッキング ストアにデータを移動することをお勧めします。 要求とユーザー間でアクセスできるようにする揮発性のデータがある場合は、この情報または操作を必要とするコンポーネントに挿入できるシングルトン サービスに簡単に格納できます。

アプリケーションの状態とその消費を維持するためのオブジェクトの構築は、次の実装のようになります。

public class MyApplicationState
{
    public int VisitorCounter { get; private set; } = 0;

    public void IncrementCounter() => VisitorCounter += 1;
}
app.AddSingleton<MyApplicationState>();
@inject MyApplicationState AppState

<label>Total Visitors: @AppState.VisitorCounter</label>

MyApplicationState オブジェクトはサーバー上に 1 回だけ作成され、VisitorCounter値がフェッチされ、コンポーネントのラベルに出力されます。 VisitorCounter値は永続化し、持続性とスケーラビリティのためにバッキング データ ストアから取得する必要があります。

ブラウザーで

アプリケーション データは、後で使用できるように、ユーザーのデバイスにクライアント側に格納することもできます。 ユーザーのブラウザーのさまざまなスコープでのデータの永続化を可能にする 2 つのブラウザー機能があります。

  • localStorage - ユーザーのブラウザー全体にスコープが設定されます。 ページが再読み込みされた場合、ブラウザーが閉じて再度開かれる場合、または別のタブが同じ URL で開かれている場合は、ブラウザーによって同じ localStorage が提供されます
  • sessionStorage - ユーザーの現在のブラウザー タブにスコープが設定されます。タブが再読み込みされると、状態は保持されます。 ただし、ユーザーがアプリケーションに対して別のタブを開くか、ブラウザーを閉じて再度開くと、状態は失われます。

これらの機能を操作するためのカスタム JavaScript コードを記述することも、この機能を提供する NuGet パッケージを多数記述することもできます。 そのようなパッケージの 1 つは Microsoft.AspNetCore.ProtectedBrowserStorage です

このパッケージを使用して localStoragesessionStorageを操作する方法については、 Blazor State Management の記事を参照してください。