ASP.NET の状態管理に関する推奨事項
更新 : 2007 年 11 月
状態管理は、同じページまたは異なるページに対する複数の要求にわたって状態およびページ情報を保持するプロセスです。すべての HTTP ベースのテクノロジについて言えることですが、Web フォーム ページは状態を持ちません。つまり、一連の要求がすべて同じクライアントからの要求かどうか、または 1 つのブラウザ インスタンスがページまたはサイトをまだアクティブに表示しているかどうかについて、自動的には示されません。また、ページはサーバーへのラウンド トリップごとに破棄されて再作成されるため、ページ情報が 1 つのページの有効期間を超えて存在することはありません。サーバーのラウンド トリップおよび Web フォーム ページの有効期間の詳細については、「ASP.NET ページのライフ サイクルの概要」を参照してください。
ASP.NET には、サーバーへのラウンド トリップ間で状態を保持するための、いくつかの方法が用意されています。これらのオプションのどれを選択するかはアプリケーションに大きく依存するため、次の基準に基づいて選択する必要があります。
どの程度の量の情報を格納する必要があるか。
クライアントが永続的な Cookie またはメモリ内の Cookie を受け入れるか。
クライアントとサーバーのどちらに情報を格納するか。
情報の機密性は高いか。
アプリケーションにおけるパフォーマンスと帯域幅の基準は何か。
対象とするブラウザおよびデバイスの機能はどのようなものか。
ユーザーごとに情報を格納する必要があるか。
どれだけの期間、情報を格納する必要があるか。
Web ファーム (複数のサーバー)、Web ガーデン (1 台のコンピュータ上での複数のプロセス)、またはアプリケーションを提供する単一のプロセスのうちどれを使用するか。
クライアント側の状態管理オプション
クライアント側のオプションを使用してページ情報を格納する場合は、サーバー リソースを使用しません。これらのオプションでは、通常、最小限のセキュリティしか提供されませんが、サーバー リソースに対する要求が大きくないため、サーバーのパフォーマンスは高速になります。ただし、クライアントに格納される情報を送信する必要があるため、この方法で格納できる情報の量には実質的な制限があります。
ASP.NET がサポートするクライアント側の状態管理オプションを次に示します。
ビューステート
コントロールの状態
隠しフィールド
Cookie
クエリ文字列
ビューステート
Web フォーム ページには、同じページに対する複数の要求の間で自動的に値を保持するための組み込み構造として、ViewState プロパティが用意されています。ビューステートはページの隠しフィールドとして保持されます。詳細については、「ASP.NET の状態管理の概要」を参照してください。
ビューステートを使用することにより、ページがポストされて戻ってくるときに、ラウンド トリップ間で独自のページ固有の値を保持できます。たとえば、アプリケーションがユーザー固有の情報 (ページで使用されるが必ずしもコントロールの一部ではない情報) を保持している場合は、その情報をビューステートに格納できます。
ビューステートを使用する場合の長所
サーバー リソースが不要 ビューステートは、ページ コード内の構造体に含まれています。
簡単な実装 ビューステートを使用する場合、カスタム プログラミングは必要ありません。既定でオンになり、コントロールの状態データを保持します。
強化されたセキュリティ機能 ビューステートの値は、Unicode 実装用にハッシュ、圧縮、およびエンコードされます。これにより、隠しフィールドよりも強固なセキュリティが提供されます。
ビューステートを使用する場合の短所
パフォーマンスに関する考慮事項 ビューステートはページ自体に格納されるため、大きな値を格納すると、ページの表示とポストにかかる時間が増大します。これは、帯域幅が制限されることが多いモバイル デバイスに特に関係します。
デバイスに関する制限事項 モバイル デバイスには、大量のビューステート データを格納するためのメモリ容量がありません。
**潜在的なセキュリティ リスク **ビューステートは、ページ上の 1 つ以上の隠しフィールドに格納されます。ビューステートにはデータがハッシュ処理されて格納されますが、改変される可能性があります。隠しフィールド内の情報は、ページの出力ソースを直接表示すると見ることができるため、セキュリティ上の問題が発生する場合があります。詳細については、「ASP.NET Web アプリケーションのセキュリティ」および「Web アプリケーションのセキュリティに関する基本的な対策」を参照してください。
コントロールの状態
ASP.NET のページ フレームワークでは、サーバーへのトリップ間でカスタム コントロール データを格納する方法として、ControlState プロパティが用意されます。たとえば、意図したとおりにコントロールを動作させるために、異なる情報を表示するさまざまなタブを持つカスタム コントロールを記述した場合、このコントロールは、ラウンド トリップ間でどのタブが選択されているかを知る必要があります。この目的にはビューステートを使用できますが、効果的にコントロールを中断するために、開発者がページ レベルでビューステートをオフにする可能性があります。コントロールの状態はビューステートのようにオフにできないため、この方法を使用すると、コントロールの状態データを格納するときの信頼性が向上します。
コントロールの状態を使用する場合の長所
サーバー リソースが不要 既定では、コントロールの状態はページ上の隠しフィールドに格納されます。
信頼性 コントロールの状態はビューステートのようにオフにできないため、コントロールの状態を管理するときの信頼性が向上します。
汎用性 カスタム アダプタを記述して、コントロールの状態データの格納方法と格納場所を制御できます。
コントロールの状態を使用する場合の短所
- プログラミングが必要 ASP.NET のページ フレームワークではコントロールの状態の基盤が提供されますが、コントロールの状態自体はカスタムの状態持続機構です。コントロールの状態を十分に活用するには、コントロールの状態の保存および読み込みを行うためのコードを記述する必要があります。
隠しフィールド
ページの状態を維持する方法の 1 つとして、ページ固有の情報をページ上の隠しフィールドに格納できます。隠しフィールドの詳細については、「ASP.NET の状態管理に関する推奨事項」を参照してください。
隠しフィールドを使用する場合は、頻繁に変更される小量のデータだけをクライアント上に格納するのが最善です。
.gif "メモ") メモ : |
|---|
隠しフィールドを使用する場合は、ページの URL (HTTP get メソッド) を使用してページを要求するのではなく、HTTP post メソッドを使用してサーバーにページを送信する必要があります。 |
隠しフィールドを使用する場合の長所
サーバー リソースが不要 隠しフィールドは格納され、ページから読み込まれます。
幅広いサポート ほとんどすべてのブラウザおよびクライアント デバイスが、隠しフィールドを持つフォームをサポートしています。
簡単な実装 隠しフィールドは、複雑なプログラミング ロジックを必要としない標準の HTML コントロールです。
隠しフィールドを使用する場合の短所
潜在的なセキュリティ リスク 隠しフィールドは、改変される可能性があります。隠しフィールド内の情報は、ページの出力ソースを直接表示すると見ることができるため、セキュリティ上の問題が発生する場合があります。隠しフィールドの内容は手動で暗号化および復号化できますが、そのためには追加のコーディングおよびオーバーヘッドが必要になります。セキュリティが問題になる場合は、重要な情報がクライアントに送信されないように、サーバー ベースの状態機構を使用することを検討します。詳細については、「ASP.NET Web アプリケーションのセキュリティ」および「Web アプリケーションのセキュリティに関する基本的な対策」を参照してください。
単純なストレージ アーキテクチャ 隠しフィールドは多様なデータ型をサポートしません。隠しフィールドには、情報として 1 つの文字列値しか格納できません。複数の値を格納するには、区切られた形式の文字列と、それを解析するコードを実装する必要があります。隠しフィールド間で、多様なデータ型を手動でシリアル化したりシリアル化を解除したりできます。ただし、そのためには追加のコードが必要になります。多様なデータ型をクライアント上に格納する必要がある場合は、代わりにビューステートを使用することを検討します。ビューステートには、隠しフィールドにデータを格納するシリアル化機能が組み込まれています。
パフォーマンスに関する考慮事項 隠しフィールドはページ自体に格納されるため、大きな値を格納すると、ページの表示とポストにかかる時間が増大します。
ストレージに関する制限事項 隠しフィールドに格納するデータが大量になると、プロキシやファイアウォールによってはデータを含むページにアクセスできません。データの最大量はファイアウォール実装やプロキシ実装によって異なるため、サイズの大きい隠しフィールドを使用すると問題が発生することがあります。多数のデータ項目を格納する必要がある場合は、次のいずれかを行うことを検討します。
個別の隠しフィールドに各項目を配置する。
ビューステート チャンク処理をオンにしてビューステートを使用する。この処理は、データを複数の隠しフィールドに自動分割します。
クライアント上にデータを格納する代わりに、サーバー上にデータを保持する。クライアントに送信するデータが増えると、ブラウザはより多くのデータをダウンロードまたは送信しなければならないため、アプリケーションの応答時間が遅くなります。
Cookie
Cookie は、頻繁に変更される小量の情報をクライアント上に格納するときに便利です。この情報は、要求と一緒にサーバーに送信されます。Cookie の作成と読み取りの詳細については、「ASP.NET の Cookie の概要」を参照してください。
Cookie を使用する場合の長所
構成可能な有効期限規則 Cookie は、クライアント上での有効期限規則に従って、ブラウザ セッションの終了時に期限切れにしたり、無期限に存在するようにしたりできます。
サーバー リソースが不要 Cookie は、クライアント上に格納され、ポストされた後でサーバーによって読み取られます。
単純さ Cookie は、単純なキーと値のペアを含む、サイズの小さなテキスト ベースの構造体です。
データの永続性 クライアント コンピュータ上での Cookie の永続性はクライアント上の Cookie 有効期限プロセスおよびユーザーの操作に左右されますが、一般に、Cookie を使用するとクライアント上で最大のデータ永続性が得られます。
Cookie を使用する場合の短所
サイズの制限 ほとんどのブラウザでは Cookie のサイズが 4,096 バイトに制限されていますが、新しいバージョンのブラウザやクライアント デバイスでは、8,192 バイトの Cookie をサポートするのが一般的になっています。
ユーザー構成による拒否 一部のユーザーは、ブラウザまたはクライアント デバイスで Cookie を受け入れる機能を無効にして、この機能を制限しています。
潜在的なセキュリティ リスク Cookie は、改変される可能性があります。ユーザーは自分のコンピュータ上で Cookie を操作できます。そのため、セキュリティ リスクが発生する可能性があります。Cookie に依存するアプリケーションで障害が発生することもあります。また、Cookie にはクライアントに Cookie を送信するドメインだけがアクセスできますが、ハッカーは、これまでユーザーのコンピュータ上の他のドメインから Cookie にアクセスする方法を見つけてきました。Cookie は手動で暗号化および復号化できますが、追加のコーディングを必要とします。また、暗号化および復号化に時間がかかるため、アプリケーションのパフォーマンスに影響する可能性があります。詳細については、「ASP.NET Web アプリケーションのセキュリティ」および「Web アプリケーションのセキュリティに関する基本的な対策」を参照してください。
メモ :Cookie は、多くの場合、既知のユーザーに対してコンテンツをカスタマイズするパーソナル化に使用されます。この場合には、認証ではなく、識別が問題になることがほとんどです。したがって、通常、ユーザー名、アカウント名、または一意のユーザー ID (GUID など) を Cookie 内に格納し、Cookie を使用してサイトのユーザー パーソナル化インフラストラクチャにアクセスすることによって、識別に使用する Cookie のセキュリティを保護します。
クエリ文字列
クエリ文字列は、ページの URL の最後に追加される情報です。詳細については、「ASP.NET の状態管理の概要」を参照してください。
クエリ文字列を使用して、ページにデータを返したり、URL を通じて他のページに送信したりできます。クエリ文字列は、いくつかの状態情報を保持するための単純な方法ですが、いくつかの制限があります。たとえば、製品番号を他のページに渡して処理する場合など、ページ間で情報を渡すためにはクエリ文字列を使用すると簡単です。
クエリ文字列を使用する場合の長所
サーバー リソースが不要 クエリ文字列は、特定の URL に対する HTTP 要求に含まれています。
幅広いサポート ほとんどすべてのブラウザおよびクライアント デバイスが、値を渡すためのクエリ文字列の使用をサポートしています。
簡単な実装 ASP.NET は、HttpRequest オブジェクトの Params プロパティを使用してクエリ文字列を読み取る方法を含め、クエリ文字列の使用を完全にサポートしています。
クエリ文字列を使用する場合の短所
潜在的なセキュリティ リスク クエリ文字列に含まれる情報は、ブラウザのユーザー インターフェイスをとおして直接ユーザーに表示されます。ユーザーは URL をブックマークに設定するか、他のユーザーに URL を送信することによって、クエリ文字列内の情報を渡すことができます。クエリ文字列内に重要情報が含まれるときは、クエリ文字列ではなく、POST を使用するフォームで隠しフィールドを使用することを検討します。詳細については、「ASP.NET Web アプリケーションのセキュリティ」および「Web アプリケーションのセキュリティに関する基本的な対策」を参照してください。
情報量の制限 一部のブラウザおよびクライアント デバイスでは、URL の長さが 2,083 文字に制限されています。
クライアント側での状態管理方法のまとめ
ASP.NET で使用できるクライアント側の状態管理オプションの一覧と、各オプションを使用する際の推奨事項を次の表に示します。
状態管理オプション |
推奨される使用法 |
|---|---|
ビューステート |
ポストバックされるページに対して小量の情報を格納する必要がある場合に使用します。ViewState プロパティを使用すると、基本セキュリティを備えた機能が提供されます。 |
コントロールの状態 |
サーバーへのラウンド トリップ間で、コントロールに対して小量の状態情報を格納する必要がある場合に使用します。 |
隠しフィールド |
ポストバックされるページ、または他のページに返されるページに対して小量の情報を格納する必要があり、セキュリティが問題とならない場合に使用します。 メモ :
隠しフィールドは、サーバーに送信されるページ上でだけ使用できます。
|
Cookie |
クライアント上に小量の情報を格納する必要があり、セキュリティが問題とならない場合に使用します。 |
クエリ文字列 |
1 つのページから別のページに小量の情報を送信する必要があり、セキュリティが問題とならない場合に使用します。 メモ :
クエリ文字列は、同じページを要求する場合、またはリンクを通じて他のページを要求する場合にだけ使用できます。
|
サーバー側の状態管理オプション
ページ情報を格納するためのサーバー側のオプションは、通常、クライアント側のオプションよりも高いセキュリティを提供します。しかし、より多くの Web サーバー リソースを使用するため、情報ストアのサイズが大きいと、スケーラビリティ上の問題につながる可能性があります。ASP.NET には、サーバー側での状態管理を実装するための、いくつかのオプションが用意されています。詳細については、「ASP.NET の状態管理の概要」を参照してください。
ASP.NET がサポートするサーバー側の状態管理オプションを次に示します。
アプリケーション状態
セッション状態
プロファイル プロパティ
データベース サポート
アプリケーション状態
ASP.NET には、アプリケーション全体で使用できるグローバルなアプリケーション固有の情報を格納する方法として、HttpApplicationState クラスによるアプリケーション状態が用意されています。アプリケーション状態変数は、実際には、ASP.NET アプリケーションのグローバル変数です。詳細については、「ASP.NET のアプリケーション状態の概要」を参照してください。
アプリケーション状態には、アプリケーション固有の値を格納できます。アプリケーション状態は、サーバーによって管理されます。詳細については、「ASP.NET の状態管理の概要」を参照してください。
アプリケーション状態変数に挿入するデータとして理想的なデータは、複数のセッションによって共有され、頻繁に変更されないデータです。
アプリケーション状態を使用する場合の長所
簡単な実装 アプリケーション状態は、使いやすく、ASP 開発者にとってなじみがあり、他の .NET Framework クラスとの整合性があります。
アプリケーションのスコープ アプリケーション状態には、アプリケーションのすべてのページからアクセスできます。したがって、情報をアプリケーション状態に格納するときには、情報のコピーが 1 つだけ保持されます。セッション状態や個別のページに情報のコピーを保持する方法とは対照的です。
アプリケーション状態を使用する場合の短所
アプリケーションのスコープ アプリケーション状態のスコープが逆に短所となることもあります。アプリケーション状態に格納された変数は、アプリケーションが動作している特定のプロセスに対してだけグローバルであり、各アプリケーション プロセスで値が異なる場合があります。したがって、Web ガーデン構成や Web ファーム サーバー構成で一意な値を格納したりグローバル カウンタを更新したりする場合には、アプリケーション状態を使用できません。
データの永続性の制限 アプリケーション状態に格納されたグローバル データは揮発性であるため、サーバーのクラッシュ、アップグレード、シャットダウンなどによって、データを含む Web サーバー プロセスが破棄されると、データが失われます。
リソースの必要条件 アプリケーション状態では、サーバーのメモリが使用されます。このことが、アプリケーションのスケーラビリティだけでなく、サーバーのパフォーマンスにも影響することがあります。
アプリケーション状態を注意深くデザインして実装することによって、Web アプリケーションのパフォーマンスを向上できます。たとえば、よく使用される比較的静的なデータセットをアプリケーション状態に格納すると、データベースへのデータ要求の総数が減るため、サイトのパフォーマンスが向上する場合があります。ただし、パフォーマンスのトレードオフが発生します。アプリケーション状態変数に大量の情報が格納されると、サーバーの負荷が増加するため Web サーバーのパフォーマンスが低下します。アプリケーション状態に格納された変数が占有するメモリは、その値が削除されるか置き換えられるまでは解放されません。したがって、最善の方法は、頻繁に変更されない小さなデータセットに対してだけアプリケーション状態変数を使用することです。詳細については、「パフォーマンスの概要」を参照してください。
セッション状態
ASP.NET には、セッション内だけで使用できるセッション固有の情報を格納する方法として、セッション状態を利用できます。セッション状態は、HttpSessionState クラスによって実現されます。ASP.NET のセッション状態は、制限された時間ウィンドウ内での同一ブラウザからの要求を 1 つのセッションとして識別し、変数値をそのセッションの存続期間中保持する機能を提供します。詳細については、「ASP.NET の状態管理の概要」および「ASP.NET セッション状態の概要」を参照してください。
セッション状態には、セッション固有の値およびオブジェクトを格納できます。セッション状態は、サーバーによって管理され、ブラウザまたはクライアント デバイスで使用できます。セッション状態変数に格納するデータとして理想的なデータは、個別のセッションに固有の、存続期間が短い重要情報です。
セッション状態を使用する場合の長所
簡単な実装 セッション状態機能は、使いやすく、ASP 開発者にとってなじみがあり、他の .NET Framework クラスとの整合性があります。
セッション固有のイベント セッション管理イベントは、アプリケーションで発生させて使用できます。
データの永続性 セッション状態変数に配置されたデータは、インターネット インフォメーション サービス (IIS: Internet Information Services) の再起動やワーカー プロセスの再起動があっても失われずに保持されます。これは、データが別のプロセス領域に格納されているためです。また、セッション状態のデータは、Web ファームや Web ガーデン内のプロセスなど、複数のプロセス間で保持できます。
プラットフォームのスケーラビリティ セッション状態は、マルチコンピュータ構成とマルチプロセス構成の両方で使用できるため、スケーラビリティを最適化できます。
Cookie なしのサポート セッション状態は、Cookie と一緒に使用して Web アプリケーションにユーザー識別機能を提供するのが最も一般的な使用法ですが、HTTP Cookie をサポートしないブラウザでも動作します。ただし、Cookie を使用せずにセッション状態を使用するには、クエリ文字列内にセッション識別子を配置する必要があります。そのため、このトピックのクエリ文字列のセクションで説明したセキュリティの問題が発生する可能性があります。Cookie を使用しないセッション状態の使用の詳細については、「ASP.NET Web サイトの管理」を参照してください。
拡張性 セッション状態は、独自のセッション状態プロバイダを記述することによってカスタマイズおよび拡張できます。その後、データベース、XML ファイル、または Web サービスなどの各種ストレージ機構に、セッション状態データをカスタム データ形式で格納できます。詳細については、「セッション状態ストア プロバイダの実装」を参照してください。
セッション状態を使用する場合の短所
- パフォーマンスに関する考慮事項 セッション状態変数は、削除されるか置き換えられるまでメモリに保持されるため、サーバーのパフォーマンスを低下させる場合があります。大きなデータセットなどの情報のブロックを含むセッション状態変数は、サーバーの負荷が増すにつれて Web サーバーのパフォーマンスに悪影響を及ぼす場合があります。
プロファイル プロパティ
ASP.NET には、ユーザー固有のデータを格納できる、プロファイル プロパティという機能が用意されています。プロファイル プロパティ機能はセッション状態機能に似ていますが、ユーザー セッションの有効期限が切れた場合でもプロファイル データが失われない点が異なります。プロファイル プロパティ機能では、永続的な形式で格納され、個々のユーザーに関連付けられる ASP.NET プロファイルを使用します。ASP.NET プロファイルを使用すると、独自のデータベースを作成したり管理したりする手間をかけずに、ユーザー情報を容易に管理できます。また、このプロファイルでは、アプリケーション内のどこからでもアクセスできる、厳密に型指定された API を使ってユーザー情報を利用できます。このプロファイルには、任意の型のオブジェクトを格納できます。ASP.NET プロファイル機能は、ほとんどの種類のデータを定義および管理できると同時に、データをタイプセーフな方法で利用できるようにする汎用ストレージ システムを提供します。詳細については、「ASP.NET プロファイル プロパティの概要」を参照してください。
プロファイル プロパティを使用する場合の長所
データの永続性 プロファイル プロパティに配置されたデータは、IIS の再起動やワーカー プロセスの再起動があっても失われずに保持されます。これは、データが外部機構に格納されているためです。また、プロファイル プロパティは、Web ファームや Web ガーデン内のプロセスなど、複数のプロセス間で保持できます。
プラットフォームのスケーラビリティ プロファイル プロパティは、マルチコンピュータ構成とマルチプロセス構成の両方で使用できるため、スケーラビリティを最適化できます。
拡張性 プロファイル プロパティを使用するには、プロファイル プロバイダを構成する必要があります。ASP.NET には、プロファイル データを SQL データベースに格納できるようにする SqlProfileProvider クラスが含まれていますが、プロファイル データをカスタム形式で格納したり、XML ファイルなどのカスタム ストレージ メカニズムや Web サービスに格納したりする独自のプロファイル プロバイダ クラスを作成することもできます。詳細については、「ASP.NET プロファイル プロバイダ」および「プロファイル プロバイダの実装」を参照してください。
プロファイル プロパティを使用する場合の短所
パフォーマンスに関する考慮事項 プロファイル プロパティは、データをメモリに格納する代わりに、データ ストアに保持します。このため、一般に、セッション状態を使用する場合よりも遅くなります。
構成に関するその他の必要条件 セッション状態とは異なり、プロファイル プロパティ機能ではかなりの構成作業が必要になります。プロファイル プロパティを使用するには、プロファイル プロバイダを構成するだけでなく、格納するすべてのプロファイル プロパティをあらかじめ構成しておく必要があります。詳細については、「ASP.NET プロファイル プロパティの概要」および「ASP.NET プロファイル プロパティの定義」を参照してください。
データの保守 プロファイル プロパティには、一定の保守作業が必要です。プロファイル データは不揮発性ストレージに保持されるため、データが古くなる前に、アプリケーションが適切なクリーンアップ機構を呼び出すように構成する必要があります。クリーンアップ機構は、プロファイル プロバイダによって提供されます。
データベースのサポート
Web サイト上で状態を管理するために、場合によってはデータベースのサポートが必要になります。通常、データベースのサポートは Cookie またはセッション状態を使って実施します。たとえば、次のような理由により、電子商取引 Web サイトではリレーショナル データベースを使用して状態情報を保持するのが一般的です。
セキュリティ
パーソナル化
一貫性
データ マイニング
Cookie がサポートされたデータベース Web サイトの一般的な機能を次に示します。
セキュリティ ユーザーは、サイトのログオン ページでアカウント名とパスワードを入力します。サイトのインフラストラクチャは、データベース内でログオン値を照会し、そのユーザーがサイトを利用する権限を持っているかどうかを確認します。データベースでユーザー情報が確認されると、Web サイトはそのユーザーの一意な ID を含む有効な Cookie をクライアント コンピュータに配布します。これにより、サイトはユーザーにアクセスを許可します。
パーソナル化 セキュリティ情報を配置すると、サイトはクライアント コンピュータ上の Cookie を読み取って各ユーザーを識別できるようになります。サイトでは、通常、一意な ID によって識別されるユーザーの基本設定を記述したデータベースに情報を格納しています。このリレーションシップをパーソナル化と呼びます。サイトは、Cookie に含まれる一意な ID を使用してユーザーの好みを調べ、ユーザー固有の要求に関連したコンテンツおよび情報を配置してユーザーの好みに対応します。
一貫性 商取引 Web サイトを作成したときに、サイト上の商品およびサービスに対する購買のトランザクション レコードを保持することが必要な場合があります。このような情報は、データベースに確実に保存し、ユーザーの一意な ID によって参照するようにできます。これにより、購買トランザクションが完了しているかどうかを確認したり、購買トランザクションに障害が発生した場合に実行するアクションを決定したりできます。この情報を使用して、サイトを利用して行った注文のステータスをユーザーに通知することもできます。
データ マイニング サイトの使用状況、利用者、または製品トランザクションに関する情報をデータベースに確実に格納できます。たとえば、ビジネス開発部門はサイトで収集されたデータを使用して、翌年の製品ラインや販売ポリシーを決定できます。また、マーケティング部門でサイトのユーザーに関する統計情報を調べることもできます。エンジニアリング部門やサポート部門では、トランザクションを調べて、購買プロセスにおいて改善できる領域を指摘できます。Microsoft SQL Server など、ほとんどのエンタープライズ レベルのリレーショナル データベースには、ほとんどのデータ マイニング プロジェクトに使用できる拡張可能なツールセットが含まれています。
上記のような状況においてサイトで状態を管理するために、一般的な各段階で一意な ID を使用してデータベースを継続的に照会するように Web サイトをデザインします。これにより、ユーザーは、サイトが自分のことを覚えていて、個人的に応答してくれるように感じます。
データベースを使用した状態管理の長所
セキュリティ データベースへのアクセスには、厳格な認証および承認が必要です。
記憶容量 データベースには大量の情報を格納できます。
データの永続性 データベースには情報を長期間にわたって格納でき、Web サーバーの可用性に左右されません。
保全性とデータの整合性 データベースには、トリガ、参照整合性、トランザクションなど、質の高いデータを維持するための各種の機能が備わっています。トランザクションに関する情報を (セッション状態ではなく) データベースに保持することにより、エラーの回復がより簡単になります。
アクセシビリティ データベースに格納されたデータは、幅広い範囲の情報処理ツールによってアクセスできます。
幅広いサポート 幅広い範囲のデータベース ツールが使用でき、多くのカスタム構成を使用できます。
データベースを使用した状態管理の短所
複雑さ データベースを使用して状態管理をサポートすると、ハードウェア構成およびソフトウェア構成の複雑さが増します。
パフォーマンスに関する考慮事項 リレーショナル データ モデルの構造が良くないと、スケーラビリティ上の問題につながる場合があります。また、データベースに対して多くのクエリを使用すると、サーバーのパフォーマンスに悪影響を及ぼす場合があります。
サーバー側での状態管理方法のまとめ
ASP.NET で使用できるサーバー側の状態管理オプションの一覧と、各オプションを使用する際の推奨事項を次の表に示します。
状態管理オプション |
推奨される使用法 |
|---|---|
アプリケーション状態 |
多くのユーザーによって使用され、頻繁に変更されないグローバルな情報を格納する必要があり、セキュリティが問題とならない場合に使用します。アプリケーション状態には、大量の情報を格納しないでください。 |
セッション状態 |
個別のセッションに固有の存続期間の短い情報を格納する必要があり、セキュリティが問題となる場合に使用します。セッション状態には、大量の情報を格納しないでください。セッション状態オブジェクトは、アプリケーション内のすべてのセッションに対して作成され、その有効期間の間保持されることに注意してください。多くのユーザーが利用するアプリケーションでは、これによって多くのサーバー リソースが占有され、スケーラビリティに影響する場合があります。 |
プロファイル プロパティ |
ユーザー セッションの有効期限が切れた後も保持され、それ以降アプリケーションにアクセスした際に再取得する必要があるユーザー固有の情報を格納する場合に使用します。 |
データベース サポート |
大量の情報を格納する場合、トランザクションを管理する場合、または、アプリケーションおよびセッションの再起動後も情報を保持する必要がある場合に使用します。データ マイニングに関心があり、セキュリティが問題となる場合。 |