ASP.NET 3.5 で状態を管理するための 6 つの手法があります (私の知る限り)。
(1) View State
(2) Cross Page Posting
(3) Query String
(4) Session State
(5) Application State
(6) Cookies
これらの手法を使用する必要がある状況の適切な例を誰か教えてもらえますか?
例えば：
(*) Session State: Personalization, Buy Cart, etc.
(*) Cookies: Saving User Credentials, etc.
これには多くの要因が影響するため、すべてについてコメントすることはできません。しかし、ここにいくつかの指針があります：
ViewState- これは、同じページに頻繁に投稿する場合に便利です (ASP.Net Webforms によって実際に強制されていること)。どのようなアプリを構築するかによって、その有用性はまったく異なります。公共のインターネット サイトの場合は、控えめに使用する必要があります。デフォルトでオフにしたい場合もあります。ローカル イントラネット サイトの場合、これは優れたツールです。特に、数が少なく重い Web フォーム ページの場合はそうです。
Query String- これを使用して、ユーザーがページまたはプロセスをブックマークして後で戻ってくることができるようにするために必要な状態を保存します。それでも、非常に巨大な URL を避けるために、データベース ルックアップでキーとして使用できる何らかの種類のハッシュに抑えたい場合があります (ただし、ハッシュには独自の問題があります)。また、多くのユーザーはクエリ文字列を直接いじるのが好きなので、ここに多くを入れすぎるのは危険です。このようにデータを表示してはならないユーザーに誤ってデータを公開することは簡単です。
Application State- これはすべてのユーザーに共有されるので、適切に使用してください。ビュー カウントなどはここに移動できます。
Cookies- ユーザー資格情報を保存するために Cookie を使用しないでください。それらは、暗号化されていない単純なテキスト ファイルです。Cookie を使用してキーをセッションに保存し (ここでも、Cookie を使用しないセッションを使用できますし、使用する必要があります)、そのユーザーとブラウザーに固有の単純なパーソナライズ設定を使用します。たとえば、職場のモニターのサイズは自宅とは異なります。ディスプレイのサイズ/レイアウトの設定を Cookie に入れると、設定がコンピューターごとに固定されるため便利ですが、他の誰かがそれを読み取ったとしても、セキュリティが損なわれることはありません。情報。
ここで、「クエリ文字列」セクションからこの概念を強調したいと思います。
データベースルックアップでキーとして使用できるある種のハッシュに抑えたい場合があります
繰り返しになりますが、ハッシュには独自の問題がありますが、クライアントの Web ブラウザーから Web サーバーへのデータのアップロードに関するリストのいくつかの項目 (クエリ文字列を含む) について指摘したいと思います: ViewState、クエリ文字列、Cookie、およびクロスページ。役職。クライアントからサーバーに移動するデータを最小限に抑えたい。この概念は、これらすべてに適用されますが、いくつかの理由があります。
したがって、ほとんどの場合、セッションにデータベース キーを保持することから始めて、そのキーに基づいてデータベースから必要なものを簡単に取得するコードを作成することをお勧めします。ボトルネックが発生したら、プロファイルを作成してボトルネックの場所を見つけ、それらのページまたはコントロールのキャッシュを開始するか、そのデータ/クエリの結果をセッションに直接保持します。
状態管理オプション
ビューの状態:
ページ自体にポストバックする少量の情報を保存する必要がある場合に使用します。ViewState プロパティを使用すると、基本的なセキュリティを備えた機能が提供されます。
制御状態:
サーバーへのラウンドトリップ間にコントロールの少量の状態情報を保存する必要がある場合に使用します。
非表示のフィールド:
ページ自体または別のページにポストバックする少量の情報を保存する必要があり、セキュリティが問題にならない場合に使用します。
非表示フィールドは、サーバーに送信されたページでのみ使用できます。
クッキー：
クライアントに少量の情報を保存する必要があり、セキュリティが問題にならない場合に使用します。
クエリ文字列：
あるページから別のページに少量の情報を転送し、セキュリティが問題にならない場合に使用します。
クエリ文字列を使用できるのは、同じページまたはリンク経由で別のページをリクエストしている場合のみです。
サーバー側の管理オプション
アプリケーションの状態
頻繁に変更されず、多くのユーザーが使用するグローバル情報を格納していて、セキュリティが問題にならない場合に使用します。アプリケーション状態に大量の情報を保存しないでください。
セッション状態
個々のセッションに固有の一時的な情報を保存していて、セキュリティが問題になる場合に使用します。セッション状態に大量の情報を保存しないでください。セッション状態オブジェクトが作成され、アプリケーションのすべてのセッションの存続期間にわたって維持されることに注意してください。多数のユーザーをホストするアプリケーションでは、これがかなりのサーバー リソースを占有し、スケーラビリティに影響を与える可能性があります。
プロファイル プロパティ
ユーザー セッションの有効期限が切れた後も永続化する必要があり、その後アプリケーションにアクセスしたときに再度取得する必要があるユーザー固有の情報を保存する場合に使用します。
データベースのサポート
大量の情報を格納する場合、トランザクションを管理する場合、または情報がアプリケーションやセッションの再起動後も存続する必要がある場合に使用します。データ マイニングが懸念事項であり、セキュリティが問題です。
(3) クエリ文字列 (4) セッション状態 (5) アプリケーション状態 (6) Cookie
1. ビューステート
/url/?p=2、Viewstate にページを保存する代わりに)2.クロスページ投稿
しないでください。ビューステートの免責事項を参照してください。これには URL を使用するか、多数のプロパティを保持する必要がある場合は、データをセッション / Cookie / プロファイルに保存します。
CPP の主な欠点は、ユーザーが Web ブラウザの [戻る] ボタンと [進む] ボタンを使用できないことです。ユーザーが戻るボタンをクリックすると、そのページのすべてを元に戻し、最後のページを再試行します。CPP を使用してウィザードでクリックする場合。この動作は、「blablablabl を再送信してもよろしいですか」というメッセージを何度も送信しないと実行できません。
3.クエリ文字列
たくさん使う。ページが到達できるすべての可視状態は、URL でアクセスできる必要があります。スクリーンリーダーを持っている人は、これに感謝します。また、クエリ文字列を使用することで、JavaScript のみのソリューションを使用する必要がなくなります。
/url/?page=2 // when doing paging, don't use postback for this
/url/?tab=advanced-search // when having tabs on top of your page
等
4. セッション状態
これは、訪問者がサイトを訪れたときにのみ意味をなす、存続期間の短いオブジェクトに使用します。例えば：
セッションではなくプロファイルを次のような目的で使用しないでください。
これらのことは、ユーザーが次にサイトにアクセスしたときにも意味があるためです.
5. アプリケーションの状態
一度もない。これには、ASP.NET キャッシュ、memcached、または任意のキャッシュ フレームワークを使用します。
6. クッキー
セッション ID、認証済みユーザーのプロファイル ID。匿名ユーザーのユーザー設定 (4. の下の 2 番目のリストに記載されているすべて)。
Application StateによるCacheオブジェクトを意味するかどうかはわかりません。
Cache オブジェクトは、アプリケーション全体の状態を管理する優れた方法です。たとえば、ソースを記録し、Web サイトへのアクセスをカウントします (たとえば、DDOS 攻撃を防ぐため)。