usando una declaración con connection.open

Question

Estaba buscando un código y discutiéndolo con mis compañeros de trabajo.

Específicamente una sección de código que se ve así.

[Test] 
    public void TestNormalWay() 
    { 
     using(var cn = GetConnection()) 
     { 
      cn.Open(); 
      // do stuff 
     } 
    } 

surgió la pregunta:

"por qué no mover el cn.Open en el método getConnection."

Dije que si "Abrir" arroja una excepción, no se deshabilitaría. Su respuesta fue

"¿Y qué? La conexión no se abrió entonces ¿por qué tendría que cerrarse (o desecharse) ?"

para mí es sólo una cuestión de no querer saber si o si no lo requiere desechar/cierre así que repetir el cn.Open en el código en lugar de moverlo a la función compartida.

PERO es interesante ... Así que hice una lectura en SQL Server Connection Pooling (ADO.NET)

Para mí no está claro si existe un escenario en el que llamar cn.Open y se lanza una excepción y en disponer lo haría necesita ser llamado.

Así que en mi siguiente ejemplo ¿Hay alguna diferencia realmente entre "TestNormalWay" y "WhyNotDoItThisWay"

protected static DbConnection GetConnection() 
    { 
     DbConnection cn = new SqlConnection("SomeConnecitonstring... "); 
     return cn; 
    } 

    protected static DbConnection GetConnectionDangerousVersion() 
    { 
     DbConnection cn = new SqlConnection("SomeConnecitonstring... "); 
     cn.Open(); // this will throw.. .dispose not called 
     return cn; 
    } 

    [Test] 
    public void TestNormalWay() 
    { 
     using(var cn = GetConnection()) 
     { 
      cn.Open(); 
      // do stuff 
     } 
    } 

    [Test] 
    public void WhyNotDoItThisWay() 
    { 
     using(var cn = GetConnectionDangerousVersion()) 
     { 
      // do stuff 
     } 
    } 

Answer 1

La forma en que está escrito el código que siempre desea para abrir la conexión tan pronto como sea creado así que no hay diferencia.

Sin embargo, puede abrir y cerrar una conexión varias veces y en el código diseñado para hacerlo hay una gran diferencia.

Es posible que desee escribir un código donde tengo una rutina de ejecución larga que toma un objeto de conexión y con el tiempo lo abre y lo cierra. Es posible que a la rutina no le importe cómo se creó el objeto de conexión. Por lo tanto, es una ventaja separar el acto de crear la conexión con el acto de abrirlo y cerrarlo.

Con respecto a la pregunta sobre la gestión de recursos, estoy de acuerdo en que no es un problema. Crear un objeto de conexión SQL en sí mismo no bloquea ningún recurso, es el acto de abrirlo el que adquiere una conexión agrupada. Si el abierto devuelve una excepción, creo que es razonable suponer que la conexión no se abrió.

Answer 2

Puede poner try/catch alrededor de la llamada .Open() en la segunda versión "peligrosa" para que, si arroja una excepción al abrir, siga desechando la conexión.

Answer 3

Me gustaría simplemente devolver la instancia del SqlConnection sin llamar al Open() en su método. Eso debe hacerse siempre y cuando sea necesario. No es necesario en su función de utilidad.

Una de las razones es que hay algunos objetos que requieren un SqlConnection, pero no necesariamente los necesitan para abrirse.Por ejemplo, un SqlDataAdapter toma un SqlConnection, y maneja la apertura y el cierre de él dentro de sí mismo. Claro, puedes abrir una conexión antes de pasarla, pero luego tienes que ser explícito al cerrarla.

Retrocediendo unos pasos, debería ser responsabilidad del código de llamada manejar exactamente qué hacer con el SqlConnection.

Answer 4

Después de llegar a las partes internas de SqlConnection estoy bastante convencido de que realmente no importa. Una prueba rápida parece confirmar esto:

static void Main(string[] args) 
{ 
    Func<SqlConnection> getConnection = 
      () => 
       { 
        var connection = 
        new SqlConnection(
         "Initial Catalog=myDatabase;Server=(local);Username=bogus;password=blah;Connect Timeout=10;"); 

        connection.Open(); 
        return connection; 
       }; 

    while(true) 
    { 
     try 
     { 
     using(var connection = getConnection()) 
     { 
      var cmd = new SqlCommand("SELECT 1", connection) {CommandType = CommandType.Text}; 
      cmd.ExecuteNonQuery(); 
     } 
     } 
     catch (Exception) 
     { 
     // ignore exception 
     } 
    } 
} 

Dejé este código ejecutándose durante un par de minutos con un generador de perfiles adjunto. No solo está funcionando bastante rápido, sino que también no está perdiendo memoria. Esto me convence bastante de que está bien abrir la conexión en su método GetConnection.

Por supuesto, todos los demás argumentos publicados aquí siguen siendo válidos; solo deberías abrir la conexión si vas a usarla de inmediato.