Объяснение буфера/кэша dapper - программирование

Я использую dapper для возврата объектов из моей базы данных как IEnumerable. По умолчанию dapper имеет настройку буфера, равную true.

Как это работает?

Если dapper кэширует первый запрос, а затем получает объекты из памяти.

Что произойдет, если кто-то отредактирует/удалит/добавит строки в таблицу. Должен ли dapper повторно использовать все данные для этого запроса?

Ответ 1

Буфер не связан с кешем. Dapper не включает в себя какой-либо кеш данных (хотя у него есть кеш, связанный с тем, как он обрабатывает команды, то есть "эта командная строка с этим типом параметра и этим типом сущности имеет связанные с ними динамически сгенерированные методы для настройки команда и заполнить объекты" ).

Что этот переключатель действительно означает:

false: будет перебирать элементы по мере их поступления/потребления - в основном, блок-итератор вокруг IDataReader
- минус: вы можете только повторять его один раз (если только вы не захотите повторно выполнить запрос)
- plus: вы можете перебирать более необъятные запросы (много миллионов строк), не требуя их сразу в памяти - так как вы только когда-либо действительно смотрите на текущую строку, /li >
- плюс: вам не нужно ждать конца данных, чтобы начать итерацию - как только у нее будет хотя бы одна строка, вы можете пойти
- минус: соединение используется во время повтора, что может привести к ошибке "есть уже открытый читатель в соединении" (или какой бы то ни было точной формулировке), если вы пытаетесь вызвать другие команды на для каждой строки (это может быть смягчено MARS).
- минус: потому что потребитель может делать все, что угодно, для каждого элемента (это может занять несколько минут в строке, если они делают что-то сложное), команда/читатель может быть открыта дольше
true (по умолчанию): данные полностью расходуются на List<T>, прежде чем он вернет вас обратно
- plus: вы можете повторять его столько раз, сколько хотите
- минус: если запрос огромен, загрузка всех их в память (в списке) может быть дорогостоящей/невозможной
- минус: если запрос большой, может быть заметная задержка, когда он собирает последнюю строку
- плюс: как только вы получите данные, команда будет завершена - значит, нет конфликта между этой и последующей операциями.
- plus: как только вы получите данные, команда уже выпустила все ресурсы (блокировки и т.д.), поэтому вы оказываете минимальное влияние на сервер

Большинство запросов возвращают только умеренный объем данных (скажем, менее 100 записей), поэтому мы рады, что значение по умолчанию (true) дает наиболее подходящее поведение для большинства сценариев. Но мы делаем этот вариант доступным для вас, чтобы обслуживать различные сценарии использования.