A conexão com o banco de dados será fechada se produzirmos a linha do datareader e não lermos todos os registros?

Ao entender como a yieldpalavra-chave funciona, deparei-me com o link1 e o link2 no StackOverflow, que defendem o uso de yield returniterações no DataReader e também atendem às minhas necessidades. Mas isso me faz pensar no que acontece, se eu usar yield returncomo mostrado abaixo e se eu não percorrer todo o DataReader, a conexão com o banco de dados permanecerá aberta para 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;
  }
}

Tentei o mesmo exemplo em um exemplo de aplicativo de console e notei, durante a depuração, que o bloco finalmente GetRecords()não é executado. Como posso garantir o fechamento do DB Connection? Existe uma maneira melhor do que usar yieldpalavras-chave? Estou tentando criar uma classe personalizada que será responsável pela execução de SQLs selecionados e procedimentos armazenados no DB e retornará o resultado. Mas não quero devolver o DataReader ao chamador. Também quero ter certeza de que a conexão será fechada em todos os cenários.

Editar A resposta foi alterada para a resposta de Ben, pois é incorreto esperar que os chamadores do método usem o método corretamente e, com relação à conexão com o banco de dados, será mais caro se o método for chamado várias vezes sem motivo.

Obrigado Jakob e Ben pela explicação detalhada.

Sim, você enfrentará o problema que descreve: até concluir a iteração sobre o resultado, manterá a conexão aberta. Há duas abordagens gerais em que posso pensar para lidar com isso:

Empurre, não puxe

Atualmente você está retornando uma IEnumerable<IDataRecord>estrutura de dados da qual você pode extrair. Em vez disso, você poderia mudar o seu método para empurrar seus resultados fora. A maneira mais simples seria passar uma Action<IDataRecord>chamada em cada iteração:

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

Observe que, como você está lidando com uma coleção de itens, IObservable/ IObserverpode ser uma estrutura de dados um pouco mais apropriada, mas, a menos que você precise, um simples Actioné muito mais direto.

Avalie Ansiosamente

Uma alternativa é garantir que a iteração seja totalmente concluída antes de retornar.

Normalmente, você pode fazer isso colocando os resultados em uma lista e depois retornando, mas nesse caso há a complicação adicional de cada item sendo a mesma referência para o leitor. Então, você precisa de algo para extrair o resultado necessário do leitor:

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

Seu finallybloco sempre será executado.

Quando você usa yield returno compilador, cria uma nova classe aninhada para implementar uma máquina de estado.

Essa classe conterá todo o código dos finallyblocos como métodos separados. Ele acompanhará os finallyblocos que precisam ser executados dependendo do estado. Todos os finallyblocos necessários serão executados no Disposemétodo

De acordo com a especificação da linguagem C #, foreach (V v in x) embedded-statementé expandido para

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

portanto, o enumerador será descartado mesmo se você sair do loop com breakou return.

Para obter mais informações sobre a implementação do iterador, leia este artigo por Jon Skeet.

Editar

O problema dessa abordagem é que você confia nos clientes da sua classe para usar o método corretamente. Eles poderiam, por exemplo, obter o enumerador diretamente e iterá-lo em um whileloop sem descartá-lo.

Você deve considerar uma das soluções sugeridas por @BenAaronson.

Independentemente do yieldcomportamento específico , seu código contém caminhos de execução que não descartarão seus recursos corretamente. E se sua segunda linha lançar uma exceção ou sua terceira? Ou até o seu quarto? Você precisará de uma cadeia try / finalmente muito complexa, ou poderá usar usingblocos.

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

As pessoas observaram que isso não é intuitivo, que as pessoas que chamam seu método podem não saber que enumerar o resultado duas vezes chamará o método duas vezes. Bem, azar. É assim que a linguagem funciona. Esse é o sinal que IEnumerable<T>envia. Há uma razão para isso não retornar List<T>ou T[]. As pessoas que não sabem disso precisam ser educadas, não contornadas.

O Visual Studio possui um recurso chamado análise de código estático. Você pode usá-lo para descobrir se você descartou os recursos corretamente.

O que você fez parece errado, mas funcionará bem.

Você deve usar um IEnumerator <> , pois também herda IDisposable .

Mas como você está usando um foreach, o compilador ainda está usando um IDisposable para gerar um IEnumerator <> para o foreach.

de fato, o foreach envolve muita coisa internamente.

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