Будет ли соединение с базой данных закрыто, если мы выдадим строку заголовка данных и не прочитаем все записи?

Понимая, как yieldработает ключевое слово, я наткнулся на link1 и link2 в StackOverflow, который поддерживает использование yield returnитерации по DataReader, и это также удовлетворяет мои потребности. Но меня удивляет, что произойдет, если я буду использовать, yield returnкак показано ниже, и если я не буду перебирать весь DataReader, будет ли соединение с БД оставаться открытым навсегда?

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

Я попробовал тот же пример в образце консольного приложения и заметил при отладке, что блок finally GetRecords()не выполняется. Как я могу обеспечить закрытие соединения с БД? Есть ли лучший способ, чем использовать yieldключевое слово? Я пытаюсь разработать собственный класс, который будет отвечать за выполнение отдельных SQL и хранимых процедур в БД и будет возвращать результат. Но я не хочу возвращать DataReader вызывающей стороне. Также я хочу убедиться, что соединение будет закрыто во всех сценариях.

Изменить Изменен ответ на ответ Бена, так как неверно ожидать, что вызывающие методы будут правильно использовать метод, и в отношении соединения с БД будет дороже, если метод вызывается несколько раз без какой-либо причины.

Спасибо Якобу и Бену за подробное объяснение.

Да, вы столкнетесь с проблемой, которую вы описываете: пока вы не закончите итерацию по результату, вы будете держать соединение открытым. Есть два основных подхода, которые я могу придумать, чтобы справиться с этим:

Тяни, не тяни

В настоящее время вы возвращаете IEnumerable<IDataRecord>структуру данных, из которой вы можете извлечь. Вместо этого вы можете переключить свой метод, чтобы вытолкнуть его результаты. Самый простой способ - передать значение, Action<IDataRecord>которое вызывается на каждой итерации:

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

Обратите внимание, что, учитывая, что вы имеете дело с набором элементов, IObservable/ IObserverможет быть немного более подходящей структурой данных, но если вам это не нужно, простое Actionгораздо проще.

Охотно оценивать

Альтернативой является просто убедиться, что итерация полностью завершена перед возвратом.

Обычно это можно сделать, просто поместив результаты в список, а затем вернув его, но в этом случае есть дополнительная сложность каждого элемента, являющаяся той же ссылкой на читателя. Так что вам нужно что-то, чтобы извлечь нужный результат из читателя:

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

Ваш finallyблок всегда будет выполняться.

При использовании yield returnкомпилятор создаст новый вложенный класс для реализации конечного автомата.

Этот класс будет содержать весь код из finallyблоков как отдельные методы. Он будет отслеживать finallyблоки, которые должны быть выполнены в зависимости от состояния. Все необходимые finallyблоки будут выполнены в Disposeметоде.

Согласно спецификации языка C #, foreach (V v in x) embedded-statementрасширен до

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

поэтому перечислитель будет удален, даже если вы выйдете из цикла с помощью breakили return.

Чтобы получить больше информации о реализации итератора, вы можете прочитать эту статью от Jon Skeet

редактировать

Проблема такого подхода состоит в том, что вы полагаетесь на клиентов вашего класса, чтобы использовать метод правильно. Они могли бы, например, получить перечислитель напрямую и проходить по нему в whileцикле, не утилизируя его.

Вы должны рассмотреть одно из решений, предложенных @BenAaronson.

Независимо от конкретного yieldповедения, ваш код содержит пути выполнения, которые не будут правильно распоряжаться вашими ресурсами. Что если ваша вторая строка выдает исключение или вашу третью? Или даже ваш четвертый? Вам понадобится очень сложная цепочка try / finally, или вы можете использовать usingблоки.

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

Люди отметили, что это не интуитивно понятно, что люди, вызывающие ваш метод, могут не знать, что при перечислении результата дважды вызовет метод дважды. Ну, удачи. Так работает язык. Это сигнал, который IEnumerable<T>посылает. Есть причина, по которой это не возвращается List<T>или T[]. Люди, которые не знают этого, должны быть образованными, а не работать вокруг.

Visual Studio имеет функцию под названием статический анализ кода. Вы можете использовать его, чтобы узнать, правильно ли вы распорядились ресурсами.

То, что вы сделали, кажется неправильным, но будет работать нормально.

Вы должны использовать IEnumerator <> , так как он также наследует IDisposable .

Но поскольку вы используете foreach, компилятор все еще использует IDisposable для генерации IEnumerator <> для foreach.

на самом деле foreach включает в себя многое изнутри.

Проверьте /programming/13459447/do-i-need-to-consider-disposing-of-any-ienumerablet-i-use