15

セッション ストレージが複数のページに対してセッション グローバルであるという理由以外に、ビューステートを使用して値を保持する必要があるのはなぜでしょうか?

値のようないくつかの小さなクエリ文字列以外のあらゆる種類の情報を、クライアントとサーバーの間でやり取りするのは、ばかげているように思えます。つまり、単にストレージの目的で帯域幅を浪費する (!) ことです。セッションは、複数のページにわたってグローバルですが、viewstate の完全に優れた代替手段のようです。

特に、asp.net の ajax コントロールとバリアントでは、viewstate がすぐに肥大化し、さまざまなコントロールと html 要素すべてのさまざまな状態と変数を追跡する可能性があります。

しかし、ページ変数とオブジェクトのビューステート ストレージが存在するのはなぜでしょうか?

ページのビューステート ストレージの別の優れた使用法を見逃している可能性があります。何か知っている人はいますか?

読んでくれてありがとう！

編集：誰もが素晴らしい答えを持っていました。あなたの答えを選ばなかったらごめんなさい。

4

8 に答える 8

22

セッションは切れますが、Viewstate は切れません。1 時間後に戻ることができ、viewstate は引き続き使用できます。Viewstate は、Web サイトで前後に移動したり、セッションが変更されたりしたときにも一貫して利用できます。

于 2009-02-22T19:44:13.687 に答える
11

ViewstateまたはSessionの全体的な理由は、Webをステートレスシステムから動的でカスタマイズされたエクスペリエンスに変えることです。ユーザーがページを要求したときに、ユーザーがエクスペリエンスを中断したところから再開できる唯一の方法は、サーバーまたはユーザーのクライアントのいずれかの状態を記憶することです。

ビューステートは、クライアント上のユーザーの状態を記憶するためのメカニズムです。セッションは、サーバー上のユーザーの状態を記憶するためのメカニズムです。

ビューステートは一時的なストレージメカニズムです。ビューステートを使用するコントロールの状態は、非表示の入力としてhtmlページにレンダリングされます。改ざんを防ぐために、署名されています。ただし、暗号化されていないため、機密情報をそこに入れないようにする必要があります。ビューステートは、一連の複数のリクエスト（ページの読み込み）にまたがって投稿する場合に役立ちます。この例としては、ユーザーが間違ったメールアドレスなどを入力したためにフォームが検証されず、ユーザーが送信する前のフォームを復元したい場合があります。これの欠点は、ビューステートが空腹の獣であり、ページサイズに30〜50％を簡単に追加できることです。

一方、セッションはサーバーに保存されます。クライアントは、どのメモリブロックが自分のものであるかをサーバーに通知するトークンを取得します。データがユーザーに何度も再送信されないため、これはビューステートよりもはるかに安全です。ただし、トレードオフがあります。サーバーのメモリが不足する可能性があります。または、セッションが中断された場合、ユーザーはデータを失う可能性があります。

一般的に、使用する「正しい」答えはありません。それはあなたが成し遂げようとしていることのすべてです。

コントロールに関係するほとんどのことは、Viewstateを使用する必要があります。ただし、機密情報を扱っている場合は、Sessionを検討してください。特定のページセットのデータがある場合は、viewstateを使用します。ユーザーがサイトにアクセスするときに必要なデータである場合は、セッションを検討してください。

于 2009-02-22T23:39:14.170 に答える
5

ViewStateとSessionのスコープは異なります。ViewStateは、「ポストバック」中に多かれ少なかれ一時的なデータを保存するように設計されていますが、セッションは重要なセッション状態データを保存するために使用されます。特定の「ページセッション」に関連する状態には、ViewStateを使用することをお勧めします。

ViewStateの通常の動作が気に入らない場合は、独自のPageStatePersisterを作成し、たとえばセッションやMemcachedなどを使用して、このオブジェクトに永続性を実行させるのは非常に簡単です。その後、デフォルトの永続性メカニズムを完全にオーバーライドできます。

次に、.NET Frameworkで標準のWebコントロールをシームレスに使用し続けることができます。これらのコントロールはすべて、ViewStateを肥大化させることなく、このタイプのデータにViewState/ControlStateを使用します。サーバーメモリの永続化メカニズムは非常に効率的です。

于 2009-02-22T21:31:01.950 に答える
5

たとえば、アプリケーションがコンピューター ファームで実行されている可能性があり、SQL サーバーを使用するようにセッションを構成できない場合です (または、SQL サーバーを使用するとパフォーマンス ヒットが多すぎます)。

于 2009-02-22T19:42:40.197 に答える
4

質問に対する直接的な回答ではありませんが、問題が解決する可能性があります。

ビューステート サーバー側に保存して、クライアントのペイロードを排除できます。

ページを継承するクラスを作成し、PageStatePersister をオーバーライドします。 http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx

 public class RussPage : Page
    {
         protected override PageStatePersister PageStatePersister
        {
            get
            {
                return new SessionPageStatePersister(Page);
            }
        }
    }
于 2009-02-23T15:38:26.407 に答える
4

ViewState は基本的に、サーバーにアップロードしてリクエストごとに解析する必要がある非表示の入力です。通常、このフィールドは自動的に入力されますが、多くの場合、プログラマーは無意識のうちに無意識に入力され、非常に大きくなる可能性があります。ブロードバンド ユーザーでもアップストリーム帯域幅が非常に限られているため、多くのサイトで問題が発生します。

すべてのユーザーがサーバーへの高速 LAN アクセスを持っているが、セッション データを保持するために使用できる RAM が限られているイントラネット サイトでは、より理にかなっています。

于 2009-02-22T19:59:00.360 に答える
2

あなたの質問に対する答えではありませんが、あなたの仮定の1つは正しくありません。

セッションIDはURLで渡すことができます。セッションにはCookieは必要ありません。

http://msdn.microsoft.com/en-us/library/aa479314.aspx

<sessionState cookieless="true" />
于 2009-02-22T21:23:35.803 に答える
1

ほとんどの場合、ビューステートの肥大化が問題にならないアプリを実行している場合は、サーバーのパフォーマンスが向上するため、ページ固有のデータをビューステートに保存することをお勧めします。さらに言えば、セッションやキャッシングに夢中になると、自分を助けるよりも自分を傷つける可能性があります。

于 2009-02-22T19:52:06.883 に答える