0

サーバーへのポストバックをトリガーできる大量のコントロールを含むページがあります。1 つのページに膨大な数のコントロールを配置することは適切な方法とは見なされていませんが、ASP.NET Web アプリケーションの性質上、それが必要です。このページには大量のコントロールがあるので、UpdatePanels を多用しています。ページの応答サイズを小さくするために、ViewState を Session に保存しています。これは美しく機能します。

ただし、Fiddler では、ajax 応答の「__VIEWSTATE」部分の後の「asyncPostBackControlIDs」に、ポストバックをトリガーできるすべての UpdatePanel のすべてのコントロールのリストが含まれていることに気付きました。このリストは巨大です！このリストはページごとにあまり変化しないように思われるため、UpdatePanel 内でポストバックが発生するたびにリスト全体をダウンロードするのは意味がありません...

ViewStateでできるようにサーバーに「asyncPostBackControlIDs」を保存する方法、または「asyncPostBackControlIDs」リストのサイズを小さくする方法はありますか?

4

1 に答える 1

1

私の知る限り、他の場所に保存するための文書化された方法はありませasyncPostBackControlIDsん-さらに、通常または非同期のポストバックを行うかどうかを決定するためにクライアント側でこれらのコントロールIDが必要になる可能性が最も高いため、そのような可能性があるかどうかは非常に疑わしいです。

UpdatePanel のChildrenAsTriggersプロパティを false に設定し、実際にポストバックをトリガーするコントロールを手動で登録できます。たとえば、Java スクリプト ハンドラーを持つ LinkBut​​ton/HyperLink がある場合があります。

さらに、ポストバックを引き起こす可能性のあるコントロールのリストを減らすことができるかもしれません。たとえば、linkbuttons/hyperlinks の代わりに anchors(a) を使用して隠し変数を設定し、(隠し) ボタンのクリックをシミュレートできます。サーバー側では、隠し変数の値は、ポストバックを担当する実際のコントロールを示します。このようにして、1 つのボタンを他の多くのコントロールのポストバック コントロールにすることができます。

最後に、あなたは非常に効率的な要求/応答ストリームを必要とし、ASP.NET 制御モデルを放棄して ASP.NET MVC を使用したいと考えている人です。または、規模が小さい場合は、AJAX の更新パネルの使用をやめ (ページの POST を完了し、ページ サイクルのほぼ全体がサーバー側で実行されます)、代わりにスクリプト サービスを (jquery プラグインと共に) 使用します。

最後に、実際の応答サイズでコントロール ID のサイズを確認する必要があります。たとえば、100K 応答内の 5K の長い ID は大きなオーバーヘッドではない可能性があります。これらの ID を減らすと、おそらく 5% の節約になりますが (可能であれば)、同じことをする価値はありますか?

于 2013-01-07T09:50:35.243 に答える