データリーダーがデータを受信したときにデータを解放する場合、列挙型を使用すると、そのデータをデータアクセス機能から呼び出し元にすぐに送り返すことができます。
リストベースのメソッドを使用する場合、リーダー全体をリストに変換するには「列挙」する必要があるため、呼び出し元はすべてのデータが受信されるのを待機します。
この理解は正しいのでしょうか。その結果、データリーダーを使用してデータアクセスコードを記述するときに、コレクションを返すためにリストを使用することを避ける方が一般的に高速ですか。
私はおそらく、リーダーを使用してデータアクセス関数でyield returnを使用するのではなく、オブジェクトのリストを初期化してオブジェクトをリストに追加し、それが返されることを意味しています。
そのとおりです。遅延評価のために即時であるだけでなく、一度に1行しか処理しないため、不要なメモリ割り当てを防ぐこともできます。
大量のデータをデータベースに残すのが最善です。
あなたがより速く意味することに依存します
私はそれをバッチ対エンドツーエンドとして見ています。
たとえば、行用に作成されたインスタンスをリーダーに表示する場合です。次に、IEnumerableを返すと、列挙しているすべてのインスタンスが作成されるのを待つという不幸な吃音なしに、チャンスとそれを実行できます。
もう1つの問題は、返品するものの寿命です。処理されるとすぐにスコープから外れる場合は、IEnumerableが最適です。これは、Listがすべてのメモリを割り当てることを意味し、IEnumerableは一度に1つで十分です。
もう1つの問題は、列挙されたアイテムの1つを処理するのにかかる時間です。読者をかなりの時間開いたままにしておくのは良い考えだとは思いませんでした。私は常に、クライアントの観点から、小さくて速いことを大いに信じてきました。データベースとの相互作用。
ですから、一般的に真実は私がそれを置く方法です。
これらはあなたが話している2つの異なる概念です。1つは接続モード（結果をできるだけ早く返すストリーミングメソッド）で作業する必要があり、もう1つは結果を取得して接続を解放します。私はここでより速くは正確な用語だとは思わない。N個のレコードがある場合、特に追加のコンピューティングが必要な場合は、クライアントに速く到達することはありません。クライアントは結果の一部をより速く見ることができますが、リスト全体ではない可能性があり（これは特定のケースごとに簡単に測定できるものです）、発信者の同期を維持するコードから追加のパフォーマンスを支払う必要があります結果とともに（並行コレクションのようなもの）。
たとえば、Web環境ではこれを行うことができますが、コードの記述/管理および同期に非常に高いコストがかかるため、ほとんどの場合、努力する価値はないと思います。