.net - ダッパーバッファ/キャッシュの説明

Question

dapperを使用して、データベースからオブジェクトをIEnumerableとして返します。デフォルトでは、dapperのバッファ設定はtrueに設定されています。

これはどのように作動しますか？

dapperが最初のクエリをキャッシュしてから、メモリからオブジェクトを取得する場合。

誰かがテーブルの行を編集/削除/追加するとどうなりますか。このクエリでは、dapperがすべてのデータを再度キャッシュする必要がありますか？

Answer 1

バッファはキャッシュとは無関係です。Dapper には、いかなる種類のデータ キャッシュも含まれていません (ただし、コマンドの処理方法に関連するキャッシュはあります。つまり、「このコマンド文字列、このタイプのパラメーター、およびこのタイプのエンティティーには、これらの関連付けられた動的に生成されたメソッドが設定されています。コマンドを実行し、オブジェクトを移入します」)。

このスイッチが実際に意味することは次のとおりです。

• false: アイテムが受信/消費されるたびに反復します。基本的には、IDataReader
  • マイナス: 1 回しか反復できません (クエリを再実行しても構わない場合を除きます)。
  • さらに、膨大な数のクエリ (数百万行) を一度にすべてメモリ内で処理する必要なく反復処理できます。
  • プラス: データの最後が反復を開始するのを待つ必要はありません - 少なくとも 1 つの行があればすぐに実行できます。
  • マイナス：反復中に接続が使用されているため、行ごとに他のコマンドを呼び出そうとすると、「接続にはすでに開いているリーダーがあります」（または正確な言い回しが何であれ）エラーが発生する可能性があります（これは MARS によって軽減できます）
  • マイナス：消費者はアイテムごとに何でもできるので（複雑なことをしている場合、行ごとに数分かかる可能性があります）、コマンド/リーダーがより長く開いている可能性があります
• true(デフォルト): データは、ユーザーList<T>に返される前に完全に消費されます。
  • プラス：好きなだけ繰り返すことができます
  • マイナス: クエリが膨大な場合、それらすべてを (リスト内の) メモリにロードすることは、コストがかかるか不可能である可能性があります
  • マイナス: クエリが大きい場合、最後の行を収集する際に顕著な遅延が発生する可能性があります
  • プラス：データを取得すると、コマンドが完了するため、その操作と後続の操作の間に競合はありません
  • プラス：データを取得するとすぐに、コマンドはすでにリソース（ロックなど）を解放しているため、サーバーへの影響は最小限です

ほとんどのクエリは中程度の量のデータ (たとえば、100 レコード未満) しか返さないためtrue、ほとんどのシナリオでデフォルト ( ) が最も適切な動作を提供することを嬉しく思います。ただし、さまざまな使用シナリオに対応するために、オプションを利用できるようにしています。