セッションでのデータの保持とポストバックでのデータの保持

Question

セッションでデータセットを維持するか、各ポストバックでデータセットを埋めることが望ましいですか？

Answer 1

それは多くの要因に依存します。通常、セッションがインプロセスまたは状態サーバー上にある場合は、セッションメモリにあまり多くのアイテムを保持しないことが最善です。スケーラビリティが低いためです。

セッションがデータベース上にある場合、クエリの実行にコストがかかる場合を除いて、データセットを再クエリおよび再入力することをお勧めします。

Answer 2

セッションを使用しないでください!!!ユーザーが別のリクエストで2番目のタブを開くと、セッションが再利用され、結果は期待したものになりません。 ViewStateとSessionの組み合わせを使用できますが、キャッシングに頼る前に、キャッシングなしで処理できる量を測定できます。

Answer 3

それをどの程度行うか、およびセッションデータがサーバー上のどこに保存されるかによります。

セッションでデータセットを保持すると、メモリ使用量に確実に影響します。すべてのセッション変数はメモリに保存されます。SQLServerの状態を使用する場合はSQLサーバーに保存されます。 State Serverモードを使用して、負荷を別のマシンにオフロードすることもできます。

シリアライゼーション/デシリアライゼーションの側面。非常に大きなデータセットを使用すると、サーバー占有のパフォーマンスに悪影響を与える可能性があります。

一方で、非常に大きなビューステートをページに持つと、パフォーマンスが著しく低下します。そのため、データセットをセッションまたはキャッシュに保持し、「outproc」を探します。そのセッションデータを保存する方法。

Answer 4

データベース操作をできる限り少なくしたいので、データをセッション中に保持しますが、それを行うための最善の方法は何かわかりません。並行性をどのように処理しますか？また、2人のユーザーが同時にページを使用するときにデータが共有されるので、セッションで各ユーザーがそれぞれ独自のデータセットを持っていることを確認するにはどうすればよいですか？

Answer 5

通常、セッションが大きすぎない場合、および/またはデータベースが遠すぎて遅い場合は、セッションを維持します。一般に、データが大きい場合は、リロードすることをお勧めします。

キャッシュを使用することがありますが、最初にDbから読み込み、キャッシュに入れます。ポストバック中に、チェックをチェックし、空の場合はリロードします。 したがって、サーバーはそれ自体でキャッシュを管理します。

Answer 6

セッションの問題は、プロセス内にある場合は消える可能性があることです。ステートサーバーの場合はシリアル化する必要があります。

結果セットが大きい場合、カスタムページングを実行して、合計結果の小さなサブセットのみを返すようにします。

複数のユーザーがこの結果セットを見ると思われる場合は、データが変更されたとき、またはアクセスされないしばらくしてからキャッシュが更新されるように、ユーザーページとして各ページをキャッシュに配置します。

多くのラウンドトリップを行いたくない場合、メモリがあると思われる場合は、キャッシュ内のデータセット全体をバングしますが、Webサーバーが溶けないように注意してください。

キャッシュを使用すると、ユーザーは独自のデータセットを必要とせず、グローバルセットを使用します。

挿入/編集ページをロードする際に並行処理が行われる限り、追加/更新後に新しいデータを入力し、キャッシュを更新する必要があります。

Answer 7

私はデカップリングを強く信じており、ユーザーインターフェイスに完全なデータセットをスローする必要性はほとんどありません。

実際に使用する必要があるUIにのみオブジェクトを渡す必要があるため、大きな図やデータ間の関係を表示する必要がある何らかのデータ構造を表示している場合を除き、費用はかかりません。

データの小さいサブセットは、該当する場合、はるかに効率的です。アプリケーションは実際にUI上のデータセット内のすべての機能を使用していますか？そうでない場合は、表示するデータのみを渡すことが最善の方法です。

コントロールにデータをバインドし、それを介して並べ替え/ページングなどを行う場合、データセットがこれをサポートできるようにする多くのインターフェイスを、非常に小さなコードで実装できます。

そのメモでは、キャッシュ内のデータは大部分が静的です（たとえば、それほど頻繁に更新されません）。そのため、この決定を実際に行う前に、データが更新される頻度を確認する必要があります。

最後に、もう一度言いますが、UIでデータセットを使用する必要は非常にまれです。非常に重いデータオブジェクトであり、データ要件を確認することのコストメリットと実装の容易さ、データセットをキャッシュする必要性をはるかに上回る可能性があります。

IMHO、パフォーマンスやメモリ使用率が心配な場合、データセットの使用はかなり悪いです。

Answer 8

回答は、データの使用を示唆していません。参照データですか？ユーザーは積極的に更新していますか？一度に複数のユーザーが更新アクセスを持つことを意図していますか？

あなたが提供したものよりも良い情報がなければ、セッション中に大量のデータを保持することは、アプリケーションがスケーリングしないことを保証する方法であり、提供するために多額のリソースを必要とするという一般的な通念に従ってください少数の人々。

通常、すべてのデータをメモリにロードすることなく、大規模なデータセットを管理するためのより良い方法があります。

これに失敗した場合、アプリケーションデータのニーズが本当に途方もないものであれば、Webサービスバックエンドを備えた重いクライアントを検討してください。 Webページを作成するよりも適している場合があります。

Answer 9

他の回答で指摘されているように、回答は「依存」します。ただし、ユーザー間で共有されるデータについて話していると仮定します。その場合、ユーザーのセッションにデータセットを保存しないでくださいが、ポストバック時に再入力する必要があります。

さらに、インタラクティブなパフォーマンスを向上させ、データベースの負荷を軽減するために、アプリケーションのデータアクセスレイヤーの近くにキャッシュを追加する必要があります。キャッシュの設計も、データのタイプに依存します（読み取り専用vs.読み取り/書き込みvs. read-mostly）。

このアプローチは、ユーザーセッション（UIレイヤーコンセプト）をデータ管理から切り離し、キャッシュデータの共有使用をサポートするという追加の利点を提供します（データがユーザー間で共通の場合）。

Answer 10

どちらでもない-「維持」しないでください何でも！ユーザーが表示する必要があるものだけを表示し、効率的なページングスキームを構築して、行を前後に表示します。

rp

Answer 11

セッションを維持します。必要に応じて、たとえばセッションメモリが消去された場合などに、再入力するオプションがあります。