DataTableオブジェクトをasp.netセッションに格納するのは悪い考えです。

Question

DataTableをasp.netのセッション変数に格納することは、サーバーのメモリを大量に使用するため、悪いことが分かります。私が理解できないことは、次のときに何をするかということです。

1. ユーザーは、（SQL Serverから）DataTableオブジェクトをロードする必要があるページが表示されます。
2. ユーザーが単純なイベントのラジオボタンをクリックします（一部のコントロールは無効になります）。
3. DataTableオブジェクトをセッションに保存しないと、セッションからフェッチするのではなく、同じページにポストバックするときにSQL Serverから再度ロードする必要がありますか？

ありがとうございました。

Answer 1

DataTableをページレベルでのみ使用する場合は、もう1つの方法はViewStateです。 ViewState["dtbl"] = DataTable;

そして、あなたはViewState単にDataTable dtbl = (DataTable)ViewState["dtbl"];

Answer 2

のDataTable年代からアクセスすることができますが、かなり重いものであり、そのことのViewStateまたはセッションに格納することが推奨されていません。ここで説明するシナリオは、データのキャッシュに関するものです。だから、なぜASP.NETのキャッシュを使用しないのですか？

ViewStateは、サーバー上でセッションまたはキャッシュとして多くのメモリを使用しませんが、サーバーでシリアル化/シリアル化解除を行う必要があり、一時的なメモリの使用が必要になります。サーバーからの各リクエストで（どのブラウザでもソースの表示を見るだけで、ベース64のエンコードされたデータでは非常に大きな隠れた入力が表示されます）。暗号化を使用しない場合は、誰でも各要求で配信されているデータをデコードすることができ、そのデータのいずれかが機密性があるとセキュリティ上の問題が発生する可能性があります。 ViewStateは少量のデータを対象としており、通常はintや文字列などの主なデータ型に固執するのが最善です。

セッションは、ユーザーあたりのメモリの負荷に加えてオーバーヘッドを追加するシリアル化/逆シリアル化も必要であるため、一般的にはお勧めできません。セッション数は、同時ユーザー数を増やすにつれて1人あたり減少するmemory limitsです。各ユーザーの実際のセッションが期限切れになるまで、セッションデータは「期限切れ」になりません。デフォルトでは30分です。セッションはユーザー固有のデータには最適ですが、int型や文字列型のようなプライマリ・データ型には非常に小さく抑えておくことをお勧めします。

キャッシュは、データのシリアル化を行わず、OSのビット数のためにlimited in sizeのみです。 Windows 2003 32ビットでは、800 MBの合計アプリケーションプールサイズが使用できます（/ 3GBスイッチを使用する場合は1.2または1.3 GB）。 64ビット環境下では、使用可能なシステムメモリの量まで構成するものだけが自由と制限が現実的にあります。キャッシュの利点は、メモリの使用量が増えるにつれて、より重要なことのためにメモリを解放するためにキャッシュが期限切れになる可能性があることです。また、メモリの圧力が要因でない場合（アイテムの有効期限が保証されていない場合）、アイテムが期限切れになる時期についても管理できます。 SQL Serverを使用している場合は、データベース内のデータにキャッシュ依存関係を置くことができます。これにより、データ自体がキャッシュを期限切れにするかどうかを決定し、新鮮なデータを確保できます。

最後に、多くの場合、のアプリケーションオブジェクトが使用できますが、ユーザー間で共有できるデータについてのみ、その情報を頻繁に変更する必要はありません。

ViewState、Session、Cache、およびApplicationオブジェクトのMicrosoftのドキュメントを使用して、それぞれのシナリオで最も賢明な使用方法を判断してください。クライアントに配信されるペイロードを減らすためにAJAX（フルページポストバックを避けるため）とHTTP圧縮を使用することに加えてこれらを正しく組み合わせることで、非常に反応の良いサイトを作ることができます。

Webファームや負荷分散などのより複雑なシナリオでは、さらに考慮すべき問題があります。あなたが自分自身に尋ねる必要がある質問は、次のようなものになります。ユーザーが最初に要求したサーバーとは異なるサーバーにヒットした場合、新しいセッションを作成する必要がありますか？ユーザーがどのサーバーにアクセスしてもキャッシュは機能しますか？これらの質問は、データを保存する場所を変更する可能性のあるソリューションにつながります。 InProcセッションは、追加のシリアル化の制限があるため、セッションサーバーとして、SQL Serverなどを使用するよりも容認されます。