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

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?¿Por qué Dapper dot net no abre y cierra la conexión?

Pregunto porque un compañero de trabajo y yo hemos estado yendo y viniendo de la naturaleza de lo que sucede tras bastidores con la agrupación de conexiones, y si hay algún beneficio para mantener una conexión abierta entre múltiples comandos, o para ábralo y ciérrelo para cada comando.

Fuente

2012-09-27 smdrager

Este cambio se ha comprometido por cierto –

vi esta mañana :) Muchas gracias. Me gusta la forma en que lo manejas ...si ya está abierto, déjalo abierto. Si está cerrado, ciérrelo cuando termine. Sencillo. – smdrager

@MarcGravell ¿Cuál es la sintaxis para el manejo de la conexión ahora? –

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

Respuesta original (obsoleta):

No está mal. 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 una DataContext, por lo que volvemos a exponer los métodos apresurados como métodos de extensión en DataContext.

El disparate es: ¿cuál de estos métodos hacen 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 null
de lo contrario, abre la conexión y devuelve un token IDisposable que cierra la conexión cuando finaliza

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

Por favor, inicie sesión como una solicitud de función. Tenemos tenemos todo el código (aunque tendré que modificarlo ligeramente para que se ajuste al "lector" de datos no almacenados en el búfer) - no hay absolutamente ninguna razón por la que el atildado no pueda apropiarse de esto.

Fuente

2012-09-27 20:01:04

¡Impresionante! Gracias. – smdrager

@Marc: ahora usamos el patrón de unidad de trabajo para manejar la conexión/TransactionScope. Si tuviéramos que eliminar el IDbConnection en el método de extensión Query (eliminando efectivamente la necesidad de manejar el estado de la conexión en el UnitOfWork), ¿no afectaría negativamente el rendimiento a múltiples consultas posteriores? –

@Chris la clave es hacer que funcione en ambos sentidos. Si desea tener una conexión que abarque varias operaciones, entonces seguro: ábrala para su unidad de trabajo (en realidad, a menudo una solicitud web completa es una unidad de trabajo). Si desea que lo maneje internamente, entonces debería ser compatible. No dejará de funcionar para lo que pretendes. Estoy más que un poco consciente de las demandas de optimización del rendimiento :) –

Creo que Dapper no administra sus conexiones ya que está fuera de sus responsabilidades como correlacionador ORM. Dapper no sabe si va a 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 que debe administrarlo, no el asignador de ORM.

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

Fuente

2012-09-27 19:56:34

No creo que esté fuera de sus responsabilidades. Está accediendo a la base de datos, ¿por qué no puede abrir la conexión cuando está lista para ejecutar un comando y cerrarla cuando termina? Es quizás un extra de 5 líneas de código. – smdrager

@smdrager Probablemente unas pocas líneas más que 5, debido a complicaciones de buffer vs no buffer, pero no puedo estar en desacuerdo contigo en el resto. –

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. Sólo he reflexionado sobre Dapper.SqlMapper y hay controles en el método ExecuteCommand (llamados a cabo por Ejecutar (en la API pública)) para comprobar si una conexión se cierra y luego se abre, si no lo es.

me encuentro con esto como una revisión de código por mi colega destacó que no estaba llamando explícitamente un connection.open antes de llamar a cabo a través de pulcro con el PP. 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.

Fuente

2014-04-02 11:26:14 brumScouse

Acabo de ver el comentario anterior de Marc sobre las connciones que se gestionan automáticamente. Disculpas por decir lo que ya saben algunos, pero no fue inmediatamente evidente cuando revisé por primera vez las respuestas. – brumScouse

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

Respuesta

Cuestiones relacionadas