データテーブルに1000個のレコードのデータを格納し、ポストバックで管理する必要があります。ビューステート（私が使用した）またはセッションに適しているオプションはどれですか。私はviewstateを使用すると、それを格納する隠しフィールドが作成され、ページの読み込みが遅くなります。セッションに格納する際にオーバーヘッド（サーバー側のメモリ消費と応答の遅延）があります。ソリューションを提案してください。パフォーマンスビューステートまたはセッションの方が良い
大量のデータの場合、セッションは効率的です。ユーザーが特定のデータブロックで完了したことを検出できる場合は、Session変数をnullに設定して、メモリーオーバーヘッドを助けます。あなたはいつもこれを行うことはできませんが、セッションは最終的に期限切れとなり、メモリはその後再利用されます。セッションタイムアウトを下げると、セッションの一部を助けることができますが、小さすぎると設定しないと、ユーザーを切断したくありません。 Web.configファイルでセッションを有効にする必要があります。
のViewState：
ここでViewStateの対セッションのための基本的な指針だのViewStateのバイナリデータ構造は、Base64では、それは1.3333回（8/6）のサイズであることを意味するページの中に置かれるように符号化されています元のバイナリデータのこのデータは、ページビューごとにアップロードおよびダウンロードされます。したがって、ViewStateに多くのものがある場合は、ページの応答時間に影響を与えます。 Base64エンコーディングはおそらく高度に最適化されているため、パフォーマンスヒットではありません。各ページリクエストは、ViewStateのスペースを割り当て、解放します。したがって、長期間のメモリヒットではありません。データはページ内にあるため、期限切れではありません。
セッション：セッション内のすべてのデータは、ページロードの間にWebサーバーに保存されます。これは、ページを小さく保ち、セッション識別子を運ぶだけです。ダウンサイドでは、セッションにデータを格納するために使用されるメモリは、セッションが期限切れになるまで割り当てられたままです。セッションがバイナリデータをコピーするのか、ポインタだけを保持するのか疑問に思っています。 Base64エンコーディングと同様に、これは高度に最適化されている可能性がありますので、パフォーマンスヒットではありません。ユーザーがページビューの間に長時間待つと、セッションが期限切れになることがあります。セッションが終了すると、ユーザーはWebページの既知の状態に戻ります。
ここでもう1つの問題は、セッションに情報を保存している場合、セッションIDがクライアントブラウザの複数のタブで共有される可能性があることです。セッションに保存されているデータをどのように使用しているかを注意する必要があります。これをテストして、ユーザーが予期しない結果を得ないようにしてください。
私はviewstateの代わりに完全にセッション変数を使用するとどうなりますか？ –
Viewstateは、ユーザーのブラウザによって維持されるため、より耐久性があります。したがって、ユーザーがページを1時間座ってどこかをクリックしても、そのセッションはおそらくViewstateを維持しますが、セッションはおそらく期限切れになります。トリックは、適切なバランスを見つけることです。 – gmlobdell
はい、あなたは正しいですが、私は何か違うものが欲しいのですが、どちらの場合でもページを読み込むのに必要なメモリ消費と時間はどれですか？ –
セッションまたはビューステートに1000個のレコードを格納しないでください。 –
ベストプラクティスは次に –
ページに必要なデータのみを取得します。グリッドをバインドするためにデータテーブルを使用している場合と同様です。データテーブルには、グリッドビューの現在のページで必要なデータのみが含まれている必要があります。 –