¿Por qué Dapper dot net no abre y cierra la conexión en sí?

.net connection-pooling dapper sqlconnection

Pregunta

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

Pregunto porque un compañero de trabajo y yo hemos estado yendo y viniendo de la naturaleza de lo que sucede detrás de las escenas con la agrupación de conexiones, y si hay algún beneficio para mantener una conexión abierta entre múltiples comandos, o para abrirla y cerrarla para cada comando.

Respuesta aceptada

Dapper ahora (y durante bastante tiempo) se ocupa de esto internamente. Simplemente funcionaâ € ¢


Respuesta original (obsoleta):

Usted no está equivocado. La razón por la que no me había dado cuenta de este inconveniente es que por razones heredadas (específicamente: solíamos usar LINQ-to-SQL exclusivamente) nuestra conexión-como-cosa primaria es un DataContext , por lo que volvemos a exponer los métodos dapper como métodos de extensión en DataContext .

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

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

Aquí EnsureOpen 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 termina

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 voy a tener que modificar ligeramente para adaptarse al "lector" para datos no amortiguada) - no hay absolutamente ninguna razón por la que apuesto no puede tomar posesión de este.


Respuesta popular

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

Me doy cuenta de esto cuando una revisión del código por parte de mi colega destacó que no llamaba explícitamente a connection.open antes de llamar a través de dapper al DB. Esto no fue recogido, ya que mis pruebas de integración eran todas verdes, todo era genial en tiempo de ejecución. Así que nos sumergimos en el código Dapper. Podría argumentarse que es mejor llamar a la claridad, pero a la inversa, algunos pueden argumentar que cuanto menos código, mejor.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow