1

データセットをセッション中に保持するか、各ポストバックでデータセットを埋めるのが望ましいですか?

4

11 に答える 11

6

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

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

于 2008-11-01T16:26:10.017 に答える
5

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

于 2008-11-04T01:18:36.587 に答える
2

それはあなたがそれをどれだけ重くするか、そしてあなたのセッションデータがサーバーのどこに保存されるかに依存します。

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

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

一方、ページに非常に大きなビューステートがあると、パフォーマンスが大幅に低下する可能性があります。したがって、データセットをセッションまたはキャッシュに保持し、そのセッションデータを格納するための「outproc」方法を探します。

于 2008-11-01T16:27:20.670 に答える
2

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

于 2008-11-01T16:47:25.013 に答える
1

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

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

于 2008-11-01T16:28:06.080 に答える
1

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

さらに、インタラクティブなパフォーマンスを向上させ、データベースの負荷を軽減するために、アプリケーションのデータ アクセス レイヤーの近くにキャッシュを設定する必要があります。キャッシュの設計は、データの種類 (読み取り専用、読み取り/書き込み、ほとんど読み取り) によって異なります。

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

于 2008-11-04T01:43:14.913 に答える
1

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

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

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

それができず、アプリケーション データのニーズが本当に膨大な場合は、Web サービス バックエンドを備えた重いクライアントを検討してください。Webページを作るより向いているかもしれません。

于 2008-11-03T01:27:03.183 に答える
1

セッションの問題は、それがproc内にある場合、それが消えてしまう可能性があることです。これは、状態サーバーの場合はシリアル化する必要があり、SQL sateの場合はとにかくラウンドトリップを行っています!

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

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

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

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

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

于 2008-11-01T17:00:41.180 に答える
1

私はデカップリングを強く信じており、完全なデータセットをユーザー インターフェイスに投入する必要があるとは、たとえあったとしてもめったに見ません。

実際には、使用する必要があるオブジェクトのみを UI に渡す必要があるため、大きな図や、データ間の関係を表示する必要があるある種のデータ構造を表示しない限り、コストに見合う価値はありません。

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

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

その点で、私はデータをキャッシュに保持しますが、これは主に静的です (たとえば、それほど頻繁に更新されません)。したがって、実際にこれを決定する前に、データが更新される頻度を確認する必要があります。

最後に、もう一度言います。UI でデータセットを利用する必要性は非常にまれです。非常に重いデータ オブジェクトであり、実装の容易さと比較して、データ要件を検討することのコスト上の利点は、データセットをキャッシュする必要性を上回ります。

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

于 2008-11-02T22:41:48.930 に答える
0

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

于 2008-11-01T16:22:01.490 に答える
0

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

rp

于 2008-11-01T16:27:35.037 に答える