La connessione al database verrà chiusa se restituiamo la riga Datareader e non leggiamo tutti i record?

Comprendendo come yieldfunziona la parola chiave, mi sono imbattuto in link1 e link2 su StackOverflow che sostiene l'uso di yield returniterando su DataReader e soddisfa anche le mie esigenze. Ma mi chiedo cosa succede se uso yield returncome mostrato di seguito e se non eseguo iterazioni sull'intero DataReader, la connessione DB rimarrà aperta per sempre?

IEnumerable<IDataRecord> GetRecords()
{
    SqlConnection myConnection = new SqlConnection(@"...");
    SqlCommand myCommand = new SqlCommand(@"...", myConnection);
    myCommand.CommandType = System.Data.CommandType.Text;
    myConnection.Open();
    myReader = myCommand.ExecuteReader(CommandBehavior.CloseConnection);
    try
       {               
          while (myReader.Read())
          {
            yield return myReader;          
          }
        }
    finally
        {
            myReader.Close();
        }
}


void AnotherMethod()
{
    foreach(var rec in GetRecords())
    {
       i++;
       System.Console.WriteLine(rec.GetString(1));
       if (i == 5)
         break;
  }
}

Ho provato lo stesso esempio in un'app console di esempio e ho notato durante il debug che il blocco di infine GetRecords()non viene eseguito. Come posso garantire quindi la chiusura di DB Connection? Esiste un modo migliore rispetto all'uso della yieldparola chiave? Sto cercando di progettare una classe personalizzata che sarà responsabile dell'esecuzione di determinati SQL e stored procedure su DB e restituirà il risultato. Ma non voglio restituire il DataReader al chiamante. Inoltre voglio assicurarmi che la connessione verrà chiusa in tutti gli scenari.

Modifica Modificata la risposta alla risposta di Ben poiché non è corretto aspettarsi che i chiamanti del metodo utilizzino correttamente il metodo e rispetto alla connessione DB sarà più costoso se il metodo viene chiamato più volte senza motivo.

Grazie Jakob e Ben per la spiegazione dettagliata.

Sì, dovrai affrontare il problema che descrivi: fino a quando non completi l'iterazione del risultato, manterrai la connessione aperta. Ci sono due approcci generali che posso pensare di affrontare questo:

Spingi, non tirare

Attualmente stai restituendo una IEnumerable<IDataRecord>struttura di dati da cui puoi estrarre. Invece, si potrebbe passare il proprio metodo per spingere i suoi risultati fuori. Il modo più semplice sarebbe quello di passare in unAction<IDataRecord> chiamata su ogni iterazione:

void GetRecords(Action<IDataRecord> callback)
{
    // ...
      while (myReader.Read())
      {
        callback(myReader);
      }
}

Tieni presente che, dato che hai a che fare con una raccolta di articoli, IObservable / IObserverpotrebbe essere una struttura di dati un po 'più appropriato, ma a meno che non ne hai bisogno, una semplice Actionè molto più semplice.

Valutare con impazienza

Un'alternativa è solo assicurarsi che l'iterazione sia completamente completata prima di tornare.

Normalmente puoi farlo semplicemente inserendo i risultati in un elenco e poi restituendoli, ma in questo caso c'è l'ulteriore complicazione di ogni elemento che è lo stesso riferimento al lettore. Quindi hai bisogno di qualcosa per estrarre il risultato che ti serve dal lettore:

IEnumerable<T> GetRecords<T>(Func<IDataRecord,T> extractor)
{
    // ...
     var result = new List<T>();
     try
     {
       while (myReader.Read())
       {
         result.Add(extractor(myReader));         
       }
     }
     finally
     {
         myReader.Close();
     }
     return result;
}

Il tuo finally blocco verrà sempre eseguito.

Quando si usa yield return il compilatore verrà creata una nuova classe nidificata per implementare una macchina a stati.

Questa classe conterrà tutto il codice dai finallyblocchi come metodi separati. Terrà traccia dei finallyblocchi che devono essere eseguiti in base allo stato. Tutti i finallyblocchi necessari verranno eseguiti inDispose metodo.

Secondo le specifiche del linguaggio C #, foreach (V v in x) embedded-statementviene espanso a

{
    E e = ((C)(x)).GetEnumerator();
    try
    {
        while (e.MoveNext())
        {
            V v = (V)(T)e.Current;
            embedded - statement
        }
    }
    finally {
        … // Dispose e
    }
}

quindi l'enumeratore verrà eliminato anche se si esce dal ciclo con breako return.

Per ulteriori informazioni sull'implementazione dell'iteratore, puoi leggere questo articolo di Jon Skeet

modificare

Il problema con tale approccio è che ti affidi ai client della tua classe per usare correttamente il metodo. Potrebbero ad esempio ottenere direttamente l'enumeratore e iterarlo attraverso awhile ciclo senza eliminarlo.

Dovresti prendere in considerazione una delle soluzioni suggerite da @BenAaronson.

Indipendentemente dal yieldcomportamento specifico , il codice contiene percorsi di esecuzione che non elimineranno correttamente le risorse. Cosa succede se la seconda riga genera un'eccezione o la terza? O anche il tuo quarto? Avrai bisogno di una catena try / finally molto complessa, oppure puoi usare i usingblocchi.

IEnumerable<IDataRecord> GetRecords()
{
    using(var connection = new SqlConnection(@"..."))
    {
        connection.Open();

        using(var command = new SqlCommand(@"...", connection);
        {
            using(var reader = command.ExecuteReader())
            {
               while(reader.Read())
               {
                   // your code here.
                   yield return reader;
               }
            }
        }
    }
}

La gente ha osservato che questo non è intuitivo, che le persone che chiamano il tuo metodo potrebbero non sapere che enumerare il risultato due volte chiamerà il metodo due volte. Bene, sfortuna. È così che funziona la lingua. Questo è il segnale che IEnumerable<T>invia. C'è un motivo per cui questo non ritorna List<T>o T[]. Le persone che non lo conoscono devono essere educate, non aggirate.

Visual Studio ha una funzione chiamata analisi del codice statico. Puoi usarlo per scoprire se hai smaltito correttamente le risorse.

Quello che hai fatto sembra sbagliato, ma funzionerà bene.

È necessario utilizzare un IEnumerator <> , poiché eredita anche IDisposable .

Ma poiché stai usando un foreach, il compilatore sta ancora usando un IDisposable per generare un IEnumerator <> per il foreach.

in effetti, la foreach implica molte cose internamente.

Controlla /programming/13459447/do-i-need-to-consider-disposing-of-any-ienumerablet-i-use