Почему Dapper dot net не открывает и не закрывает соединение?

Dapper неявно ожидает, что соединение будет открыто при его использовании. Почему он не открывает и не закрывает его сам? Разве это не просто управление соединением?

Я спрашиваю, потому что со-работник и я возвращались назад и вперед по поводу того, что происходит за кулисами с пулом соединений, и если есть какая-либо польза для поддержания соединения между несколькими командами или для открытия и закройте его для каждой команды.

ОТВЕТЫ

Ответ 1

Теперь Dapper (и довольно долгое время) занимается этим внутренне. Он просто работает ™

Оригинальный (устаревший) ответ:

Ты не ошибаешься. Причина, по которой я не заметил, что это неудобство заключается в том, что по причинам, связанным с устаревшими (в частности: мы использовали LINQ-to-SQL исключительно), наша основная информация о подключении - это DataContext, поэтому мы повторно выставляем методы dapper как методы расширения на DataContext.

Глупая вещь: что делают эти методы:

using(db.Connection.EnsureOpen()) {
    db.Connection.{the dapper method}
}

Здесь EnsureOpen - это нахальный метод, который:

  • если соединение открыто, возвращает null
  • В противном случае он открывает соединение и возвращает маркер IDisposable, который закрывает соединение при завершении

Итак: мы, очевидно, чувствовали именно вашу боль, но мы реализовали его еще дальше.

Пожалуйста, зарегистрируйте это как запрос функции. У нас есть весь код (хотя мне нужно немного подстроить его, чтобы он соответствовал "читателю" для небуферизованных данных) - нет абсолютно никакой причины, по которой dapper не может владеть этим.

Ответ 2

Я должен добавить здесь противоположный ответ или, по крайней мере, предположить, что Dapper может обрабатывать соединения по-разному, если только в определенных обстоятельствах. Я только что подумал над Dapper.SqlMapper и есть проверки в методе ExecuteCommand (вызывается Execute (public api)), чтобы проверить, закрыто ли соединение и затем оно открывается, если это не так.

Я сталкиваюсь с этим, так как обзор кода моим коллегой подчеркнул, что я не вызывал явного вызова connection.open перед вызовом через dapper в БД. Это не было воспринято, так как мои интеграционные тесты были зелеными, во время работы все было неудобно. Таким образом, мы погрузились в код Dapper. Можно утверждать, что его лучше назвать открытым для объяснения, но, наоборот, некоторые могут утверждать, что чем меньше код, тем лучше.

Ответ 3

Я считаю, что Dapper не управляет вашими подключениями, поскольку он не входит в его обязанности как ORM-карппер. Dapper не знает, будет ли вы повторно использовать одно и то же соединение позже - поэтому он принимает соединение в качестве одного из параметров. То же самое относится к транзакциям - это приложение, которое должно управлять им, а не ORM-mapper.

Тривиально писать собственные методы расширения, которые управляют соединением.