.net - pools - ¿Por qué Dapper dot net no abre y cierra la conexión?

sql connection pools

Question

Dapper espera implícitamente que una conexión esté abierta cuando la use. ¿Por qué no se abre y se cierra? ¿No sería esto simplemente la gestión de la conexión?

Lo pregunto porque un compañero de trabajo y yo hemos estado yendo y viniendo sobre la naturaleza de lo que sucede detrás de escena con la agrupación de conexiones, y si hay algún beneficio en mantener una conexión abierta entre varios comandos, o para abrirla y cerrarla. para cada orden.

Answer 1

Creo que Dapper no administra sus conexiones ya que está fuera de sus responsabilidades como ORM mapper. Dapper no sabe si reutilizará la misma conexión más adelante, por eso acepta una conexión como uno de los parámetros. Lo mismo se aplica a las transacciones: es la aplicación la que debe administrarlo, no el asignador de ORM.

Es trivial escribir métodos de extensión propios que gestionan la conexión.

Answer 2

Dapper ahora (y desde hace bastante tiempo) trata esto internamente. Simplemente funciona ™

Respuesta original (desactualizada):

No estas equivocado La razón por la que no había notado este inconveniente es que por razones heredadas (específicamente: solíamos usar LINQ-to-SQL exclusivamente) nuestra conexión principal es un DataContext , por lo que reexponemos los métodos Dapper como métodos de extensión en DataContext .

Lo tonto es: lo que hacen estos métodos es:

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

Aquí Asegurarse es un método descarado que:

• Si la conexión está abierta, devuelve nulo.
• de lo contrario, abre la conexión y devuelve un token IDisposable que cierra la conexión cuando se hace

Entonces: obviamente sentimos exactamente tu dolor, pero lo implementamos una capa más arriba.

Por favor registre esto como una solicitud de función. Tenemos todo el código (aunque necesitaré modificarlo ligeramente para que se ajuste al "lector" de los datos no almacenados en búfer), no hay ninguna razón para que Dapper no pueda hacerse cargo de esto.

Answer 3

Tengo que agregar una respuesta contraria aquí, o al menos sugerir que Dapper puede manejar las conexiones de manera diferente, aunque solo sea en ciertas circunstancias. Acabo de reflexionar sobre Dapper.SqlMapper y hay verificaciones en el método ExecuteCommand (llamado por Execute (en la api pública)) para verificar si una conexión está cerrada y luego la abre, si no lo está.

Me encontré con esto cuando un colega revisó el código y destacó que no estaba llamando explícitamente a una conexión. Antes de llamar a la base de datos, abra antes de llamar. Esto no se detectó, ya que mis pruebas de integración eran todas verdes, todo estaba hecho en tiempo de ejecución. Así que nos sumergimos en el código Dapper. Podría argumentarse que es mejor dejarlo abierto para una explicación explícita, pero a la inversa, algunos pueden argumentar que cuanto menos código mejor.