using statement with connection.open

Question

Stavo guardando un po 'di codice e discuto con i colleghi di lavoro.

In particolare una sezione di codice simile a questa.

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

La domanda si avvicinò:

"Perché non spostare il cn.Open nel metodo GetConnection."

Ho detto che se "Apri" genera un'eccezione, non viene chiamata. La sua risposta è stata

"Allora, la connessione non è stata aperta, quindi perché sarebbe necessario ottenere chiuso (o smaltito)?"

per me è solo una questione di non voler sapere se o se non ho bisogno di smaltire/chiudere quindi vorrei ripetere il cn.Open nel codice invece di spostarlo nella funzione condivisa.

MA è interessante ... così ho fatto qualche lettura SQL Server Connection Pooling (ADO.NET)

Per me non è chiaro se esiste uno scenario in cui chiamare cn.Open e getta e l'eccezione in cui dispose sarebbe bisogno di essere chiamato.

Così, nel mio esempio qui sotto v'è alcuna differenza davvero tra "TestNormalWay" e "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

Il modo in cui si sta scrivendo il codice che hai sempre desidera per aprire la connessione non appena è creato così non c'è differenza.

Tuttavia è possibile aprire e chiudere una connessione più volte e in codice progettato per fare ciò c'è una grande differenza.

Potrei voler scrivere del codice dove ho una lunga routine in esecuzione che accetta un oggetto di connessione e nel tempo apre e chiude. La routine potrebbe non interessare come è stato creato l'oggetto di connessione. Quindi è un vantaggio separare l'atto di creare la connessione con l'atto di aprirlo e chiuderlo.

Per quanto riguarda la domanda di gestione delle risorse, sono d'accordo che non è un problema. La creazione di un oggetto di connessione SQL in sé non blocca alcuna risorsa, è l'atto di aprirlo che acquisisce una connessione in pool. Se l'open restituisce un'eccezione, penso sia ragionevole presumere che la connessione non sia stata aperta.

Answer 2

È possibile mettere un tentativo/aggirare la chiamata .Open() nella seconda versione "pericolosa" in modo che se genera un'eccezione durante l'apertura, si sta ancora eliminando la connessione.

Answer 3

Sarei propenso a restituire l'istanza dello SqlConnection senza chiamare il numero Open() nel metodo. Questo dovrebbe essere fatto se e quando è necessario. Non è necessario nella funzione di utilità.

Uno dei motivi è che alcuni oggetti richiedono uno SqlConnection, ma non necessariamente devono essere aperti.Ad esempio, uno SqlDataAdapter prende uno SqlConnection e ne gestisce l'apertura e la chiusura al suo interno. Certo, puoi aprire una connessione prima di passarla, ma poi devi essere esplicito chiudendolo.

Fare qualche passo indietro, dovrebbe essere la responsabilità del codice chiamante per gestire cosa esattamente fare con lo SqlConnection.

Answer 4

Dopo aver raggiunto il picco interno di SqlConnection sono praticamente convinto che non importa. Un test rapido sembra confermare questa:

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 
     } 
    } 
} 

ho lasciato questo codice in corsa per un paio di minuti con un profiler allegato. Non solo è in esecuzione abbastanza veloce, ma non perde nemmeno memoria. Questo praticamente mi convince che sia ok per aprire la connessione nel metodo GetConnection.

Ovviamente tutti gli altri argomenti pubblicati qui sono ancora validi; dovresti solo aprire la connessione se la userai subito.