問題タブ [viewstate]

これが ASP.NET で可能かどうかはわかりませんが、ここに問題があります。Web アプリケーションのデータ リストの一部がGridViewを使用して表示されます。ただし、これらのリストの一部には大量のデータが含まれている可能性があるため、 ViewStateによってページの重量が数メガバイトの範囲に押し上げられることがあります。ページにポストバックがあるたびにこの情報についてデータベースを再クエリしたくないので、サーバー上のコントロールに与えられたデータをキャッシュして、次回アクセスする方法があるかどうか疑問に思っていましたポストバックがあります。

それで、これは可能ですか？もしそうなら、誰かがこれを行う方法に関する詳細情報の方向に私を向けることができますか? 不可能な場合、この問題を解決する方法について何か提案はありますか?

ScriptResource.axd に関して無効なビューステート エラーが発生します。あなたの誰かがこれについて私を助けることができるかどうか疑問に思っています。エラーは次のとおりです。

これは本番環境で発生します。これを開発環境やテスト環境で再現することはできません。また、これらのページには、認証されたユーザーのみがアクセスできます。この問題に光を当てることができれば、本当にそうです。

ASP.NETプロジェクトの1つを再構築し始めようとしています。これは、viestateをオン（web.configで無効）にせずに開発してみたいと思います。

ビューステートの長所と短所について知っており、一般的に、コントロールステートと比較して何を追跡しているのかを知っていますが、知りたいのは次のとおりです。

1. 主な開発プロセスの違いは何ですか？つまり、Page_Loadなどの構造はどのように異なりますか？

2. ビューステートをオンにしないと実際には機能しない標準のASP.NETコントロールの機能はありますか？

また、VSを使用する場合と使用しない場合のワークフローの違いに関する詳細な記事はありますか？

ASP.NET がどのビュー ステートを保持しているかを理解するために、コントロール インフラストラクチャに頭を悩ませようとしています。

これらの通常の HTML コントロールがあります。例: <input type="radio" checked="checked"/>-> これらにはビューステートがないことを理解しています

次に、runat="server" を含む HTML コントロールがあります <input type="radio" checked="checked" runat="server"/>-> ビューステートはポストバック間で維持されますか?

次に、ASP.NETコントロールがあります <asp:TextBox id="txtMyText" runat="server"/>->これらにはビューステートがあることを理解しています

HtmlTextBox を継承するカスタム コントロールがいくつかあります <myPrefix:myTextBox id="txtMyText" runat="server"/>-> これは上記のタイプ 2 と同じですか?

runat="server"タグを持つコントロールはビューステートを維持していると想定しても安全ですか?

動的に作成されたコントロール (TextBox と DropDownList) を含むページがあります。ポストバックが発生すると、TextBox は値を保持しますが、DropDownList は ListItem を失います。ページ レベルの DropDownList もその ListItems を保持するため、これは非常に紛らわしいです。以下のコードの何が問題なのか、誰にもわかりますか?

この問題を解決するための助けをいただければ幸いです。

ページ上のユーザー コントロールでは、すべてのコントロールが ViewState に独自の状態を格納することでメモリ使用量に影響を与えることを理解しています。私の質問は、いくらですか？

たとえば、マスターページのコントロールとしてフィードバック フォームがあります。デフォルトでは Visible="false" に設定されています。ユーザーがフィードバック ボタンをクリックすると、必要なときにコントロールが表示されます。

コントロールをすべてのページ (マスターページに配置されているため) に配置するが、目に見えない場合の相対的なパフォーマンスへの影響はどうなるでしょうか? 私が開発しているサイトには大量のトラフィックが発生する可能性があり、後で処理が遅くなった場合に頭痛の種になるのではないかと考えています。

ありがとう

ここに私のセットアップの基本があります：

System.Web.UI.Page から継承する BasePage クラスがあります。BasePage には 2 つのプロパティが実装されており、その get/set が ViewState コレクション内の 2 つの異なる項目から実行されるようになっています (例: BasePage の this.ViewState["Year"])。

BasePage から継承する別のクラスがあります。それを SpecificBasePage と呼びましょう。

最後に、SpecificBasePage を継承する aspx ページがあります。

ブレーク ポイントを追加し、コードを何度も実行したところ、最初のページ ロードで両方のビュー ステート プロパティに値が割り当てられ、最初のページ ロードのライフ サイクル全体で値が保持されることがわかりました。

ただし、ページがポストバックされると、Page_Load イベントおよびその他のイベント ハンドラー (ViewState をロードする必要がある場合) で、両方のプロパティが null を返します。this.ViewState.Count を調べると、コレクションにオブジェクトがないことがわかります。

ViewState に影響を与え、この動作を引き起こす可能性のあるどこかで私が行っていることを誰かが考えることができますか?

-- さらに、コードの一部に分離しました。初期ロード時に、OnInit でビューステート プロパティの値を指定します。これを OnLoad に移動すると、ポスト バック全体で値が保持されることがわかりました。追加されたビュー ステートの値は最初のページのライフサイクル全体で保持されますが、ポスト バックで破棄されますか?

ASP.NET MVC が「通常の」ASP.NET から移行する価値があるかどうかについて、いくつかの SO 記事を読みました。私が引用した MVC を使用する最大の理由の 1 つは、Viewstates を使用する必要がないことでした。

ただし、この記事に示すように、ビューステート情報をサーバーに保存することで、ビューステートを排除することができます。サンプル プロジェクトで試してみましたが、うまく機能し、気づいた限りでは完全に透過的で、実装も非常に簡単でした。

それで、キャッチはどこですか？サーバーの負荷が少し高くなると思いますが、本当にそんなに悪いのでしょうか? そうでない場合、ビューステートについて不満を言う代わりに、このアプローチを使用する人が増えないのはなぜですか?