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

Question

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

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

Answer 1

Даппер сейчас (и довольно долго) занимается этим внутренне. Это просто работает ™

---

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

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

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

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

Здесь EnsureOpen - это дерзкий метод, который:

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

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

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

Answer 2

Здесь я должен добавить противоположный ответ или, по крайней мере, предположить, что Даппер может обрабатывать соединения по-разному, хотя бы при определенных обстоятельствах. Я только что размышлял над Dapper.SqlMapper, и в методе ExecuteCommand есть проверки (вызванные Execute (на общедоступном API)), чтобы проверить, закрыто ли соединение, а затем открывает его, если нет.

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

Answer 3

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

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