¿Se cerrará la conexión de la base de datos si obtenemos la fila del lector de datos y no leemos todos los registros?

Mientras que la comprensión de cómo yieldfunciona la palabra clave, me encontré con Link1 y Link2 en StackOverflow que aboga por el uso de yield returntiempo interactuando sobre el DataReader y se adapta a mi necesidad también. Pero me pregunto qué sucede si uso lo yield returnque se muestra a continuación y si no repito todo el DataReader, ¿la conexión de la base de datos permanecerá abierta para siempre?

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

Intenté el mismo ejemplo en una aplicación de consola de ejemplo y noté durante la depuración que el bloque finalmente GetRecords()no se ejecuta. ¿Cómo puedo asegurar el cierre de DB Connection? ¿Hay una mejor manera que usar yieldpalabras clave? Estoy tratando de diseñar una clase personalizada que se encargará de ejecutar SQL seleccionados y procedimientos almacenados en la base de datos y devolverá el resultado. Pero no quiero devolver el DataReader a la persona que llama. También quiero asegurarme de que la conexión se cerrará en todos los escenarios.

Editar Cambió la respuesta a la respuesta de Ben, ya que es incorrecto esperar que quienes llaman al método usen el método correctamente y con respecto a la conexión de la base de datos, será más costoso si el método se llama varias veces sin razón alguna.

Gracias Jakob y Ben por la explicación detallada.

Sí, enfrentará el problema que describe: hasta que termine de iterar sobre el resultado, mantendrá la conexión abierta. Hay dos enfoques generales en los que puedo pensar para lidiar con esto:

Empujar, no tirar

Actualmente está devolviendo una IEnumerable<IDataRecord>estructura de datos que puede extraer. En cambio, podría cambiar su método para sacar sus resultados. La forma más sencilla sería pasar un Action<IDataRecord>que se llama en cada iteración:

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

Tenga en cuenta que dado que se trata de una colección de elementos, IObservable/ IObserverpodría ser una estructura de datos ligeramente más apropiada, pero a menos que la necesite, una simple Actiones mucho más sencilla.

Evaluar con entusiasmo

Una alternativa es simplemente asegurarse de que la iteración se complete por completo antes de regresar.

Normalmente puede hacer esto simplemente colocando los resultados en una lista y luego devolviéndolo, pero en este caso existe la complicación adicional de que cada elemento sea la misma referencia para el lector. Entonces necesita algo para extraer el resultado que necesita del lector:

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

Su finallybloqueo siempre se ejecutará.

Cuando use yield returnel compilador creará una nueva clase anidada para implementar una máquina de estados.

Esta clase contendrá todo el código de los finallybloques como métodos separados. Realizará un seguimiento de los finallybloques que deben ejecutarse según el estado. Todos los finallybloques necesarios se ejecutarán en el Disposemétodo.

De acuerdo con la especificación del lenguaje C #, foreach (V v in x) embedded-statementse expande a

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

entonces el enumerador se eliminará incluso si sale del bucle con breako return.

Para obtener más información sobre la implementación del iterador, puede leer este artículo de Jon Skeet

Editar

El problema con este enfoque es que confía en los clientes de su clase para usar el método correctamente. Podrían, por ejemplo, obtener el enumerador directamente e iterarlo en un whilebucle sin desecharlo.

Debería considerar una de las soluciones sugeridas por @BenAaronson.

Independientemente del yieldcomportamiento específico , su código contiene rutas de ejecución que no eliminarán sus recursos correctamente. ¿Qué pasa si su segunda línea arroja una excepción o su tercera? ¿O incluso tu cuarto? Necesitará una cadena de prueba / finalmente muy compleja, o puede usar usingbloques.

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 comentado que esto no es intuitivo, que las personas que llaman a su método pueden no saber que enumerar el resultado dos veces lo llamará dos veces. Bueno, mala suerte. Así funciona el lenguaje. Esa es la señal que IEnumerable<T>envía. Hay una razón por la cual esto no regresa List<T>o T[]. Las personas que no saben esto necesitan ser educadas, no evitadas.

Visual Studio tiene una característica llamada análisis de código estático. Puede usarlo para averiguar si ha eliminado los recursos correctamente.

Lo que hiciste parece estar mal, pero funcionará bien.

Debe usar un IEnumerator <> , ya que también hereda IDisposable .

Pero debido a que está utilizando un foreach, el compilador sigue utilizando un IDisposable para generar un IEnumerator <> para el foreach.

de hecho, el foreach involucra muchas cosas internamente.

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