質問: Dapper dot netは`buffer`パラメータ(ブール値)を持っていますが、それを返すことができる*唯一の*ことを言えばそれを返す前にリストに結果をキャストすることです。 ドキュメントに従って: > Dapperのデフォルトの振る舞いはあなたのsqlを実行し、戻ったときに全体の読者をバッファすることです。これは、db内の共有ロックを最小限に抑え、dbネットワーク時間を短縮するため、ほとんどの場合理想的です。 > > ただし、巨大なクエリを実行するときは、メモリ使用量を最小限に抑え、必要に応じてオブジェクトのみをロードする必要があります。そのためには、buffered:Queryメソッドにfalseを渡します。 > > 結果をリストにキャストすることでこれがどのように達成されるかわかりません。私は何かが足りないのですか?私の唯一のアイデアは、設定することになっているということである`CommandBehavior`ため`ExecuteReader`に`CommandBehavior.SequentialAccess` (しかし、それはしていません)。
回答: > しかし、私が唯一のことは、結果をリストにキャストして返すことです > > あなたは何も欠けていません。それが重要な違いです。実際に返されるオブジェクトは非常に異なっている:それはのような*キャスト*ではありません除きます。基本的に、データを読み取るには2つの方法があります。 * ストリーミングAPIでは、各要素が個別に生成されます。これは非常にメモリ効率が良いですが、アイテムごとに後続の処理をたくさん行う場合、接続/コマンドが長時間「アクティブ」になる可能性があります * バッファされたAPIで何かが生成さ*れる前に*すべての行が読み込まれます 非常に大量のデータ(数千から数百万行まで)を読み込んでいる場合は、バッファされていないAPIが望ましいかもしれません。さもなければ、たくさんのメモリが使用され、最初の行が利用可能になる前に顕著な待ち時間があるかもしれません。しかし、ほとんどの一般的なシナリオでは、読み込まれるデータの量は妥当な範囲内であるため、呼び出し元に渡す前にリストにプッシュするのが妥当です。これは、コマンド/リーダーなどが完了**する前**に返さ**れる**ことを意味します。 さらに、バッファされたモードでは、あまりにも一般的な「接続上に既に開いているリーダーがあります」(または正確なフレーズが何であれ)を避けることができます。