2

私は自分のページで（それが不可能でない限り）を使用してすべてGridViewsをバインドするなどを使用しました。最近、私はすべてのコントロールをプログラムでバインドし始めました。一部の人は同意しないかもしれませんが、私はこれがはるかにクリーンで簡単だと思います。DetailViewsObjectDataSource

ObjectDataSourceプログラムで行うのと同様に、明らかにバインドには長所と短所があります。

GridViewをプログラムでバインドするとします（たとえばGridView1.DataSource = SomeList）。GridViewのページを変更するときは、これもコーディングする必要があります。ページが変わるたびに、GridView1.DataSource = SomeListもう一度電話する必要があります。明らかに、ObjectDataSource私はこれを行う必要はありません。私は通常、SomeListオブジェクトをViewStateに貼り付けているので、ページを変更するときに毎回データベースにアクセスする必要はありません。

私の質問は：これはObjectDataSourceがどのように機能するのですか？データをViewStateに保存し、.Selectメソッドを呼び出さない限りデータベースに再度アクセスしませんか？私は自分のアプリケーションから最高のパフォーマンスを引き出し、データベースにできるだけ少ない回数アクセスするのが好きですが、ViewStateに巨大なリストを保存するというアイデアはあまり好きではありません。これを行うためのより良い方法はありますか？ユーザーごとのキャッシュは良い考えですか（または可能ですか）？巨大なリストをViewStateに保存する代わりに、毎回データベースにアクセスするだけでよいでしょうか。ViewStateを使用するよりも、データベースにアクセスする方が良い場合がありますか？

4

1 に答える 1

1

.Select メソッドを呼び出さない限り、データを ViewState に保存し、データベースに再度ヒットしませんか?

いいえ、データを ViewState に保存しません。ビュー ステート グリッドビューおよびその他の同様のリストでは、並べ替え列、ページ、合計ページ、コントロールの状態などの一般的なステータスを保存しますが、データは保存しません。

ユーザーごとのキャッシュは良い考えですか

サーバー側でのユーザーごとのキャッシュは、キャッシュが数分間しか持続しない場合や、キャッシュするデータが非常に小さい場合を除いて、あまり良い考えではありません。ユーザーごとに大量のデータを長時間キャッシュすると、特にユーザーが大量のページを読み始めた場合にデータが大きくなりすぎて、最終的に同じ問題が発生します。

多くのテーブルのリレーションから得られる大量のデータを表示する必要がある場合は、テーブルの完全なリレーションを「1 つのフラット テーブル」にキャッシュする方がよい場合があります。

巨大なリストを ViewState に保存する代わりに、毎回データベースにアクセスする必要がありますか?

これは、データの読み取りを設計する速度にも依存します。私にとっては、ViewState を小さく保ち、データではなく、ページでアクションを実行するために必要な情報のみを保持することをお勧めします。

于 2010-11-16T11:08:22.653 に答える