5

状態管理に関する Microsoft の記事を読んでいました。

http://msdn.microsoft.com/en-us/library/75x4ha6s(v=vs.100).aspx

ここで興味深いものを見つけました。ViewState はクライアント側のオプションに分類されます (私は既に知っていましたが)。アプリケーションのコードを思い出します。

DataTable dt = getDatatableFromDB();
ViewState["dataTable"] = dt;

そして、このコードは現時点では正常に機能しています。

私の混乱は次のとおりです。

  1. クライアント側オブジェクト(ViewState)はサーバー側オブジェクト(Datatable)をどのように保存できますか?
  2. Datatables のような大きなオブジェクトを格納するために ViewState を使用することは良い習慣ですか?
  3. このアプローチを使い続けると、どのような副作用が生じる可能性がありますか?
4

2 に答える 2

8

ビューステートは、フォームの隠し<input />タグに保存されます。ユーザーが (ボタンをクリックするなどして) ポストバックを開始すると、データはフォーム データの一部としてサーバーに返されます。

ViewState に大量のデータを保存すると、ユーザーがページをダウンロードしようとしたとき (すべてのデータが HTML の一部になるため) と、ユーザーがフォームを送信しようとしたとき (すべてのデータが HTML の一部になるため) の両方でペナルティが発生します。データはサーバーにアップロードする必要があります)。

さらに、ViewState は簡単に失われます。ユーザーがフォームを送信している間のみ保持されます。ユーザーが別のページへのハイパーリンクをクリックすると、フォームは送信されず、ViewState に含まれるすべてのデータが失われます。これは、アンカー タグがユーザーが現在いるページを指している場合でも当てはまります。

以前の質問から、DataTable を配置するのに適した場所を見つけようとしていることがわかります。データが比較的小さい限り、ViewState は最悪の場所ではありません。Base64 はメモリ使用量の点では XML よりも優れていますが、効率的とは言えません。データがかなり静的な場合は、 ApplicationStateに格納することを検討してください。GridView を使用して DataTable を編集している場合、GridView は実際にはDataSourceプロパティを介してアクセスできる DataTable を既に格納しています (DataTable にキャストするだけです)。

また、ViewState データは base64 でエンコードされていますが (平均的なユーザーには理解できないことを意味します)、熱心なユーザーであれば簡単に編集できることにも注意してください。一見無害なデータが編集されて、Web サイトにとって非常に有害になる可能性があります。これはウェブサイトをハッキングするための古典的な手段であるため、どのデータを正確に保存するかについて非常に注意する必要があります. たとえば、ユーザーの ID を ViewState に保存すると、ユーザーは ID を編集して、別のユーザーのアカウントに侵入する可能性があります。(注: これは、EnableViewStateMac が に設定されている場合のみの問題ですFalse。 )

于 2012-10-11T04:28:19.647 に答える
4

1) クライアント側オブジェクト (ViewState) はサーバー側オブジェクト (Datatable) をどのように保存できますか?

シリーズ化されています。

2) Datatables のような大きなオブジェクトを格納するために ViewState を使用することは良い習慣ですか?

ご使用の環境と要件によって異なります。

3) このアプローチを使い続けた場合、どのような副作用が生じる可能性がありますか?

多くのデータがネットワーク上を移動します。それは物事を遅くする可能性があります。

于 2012-10-11T04:30:05.157 に答える