Czy połączenie z bazą danych zostanie zamknięte, jeśli otrzymamy wiersz modułu danych i nie odczytamy wszystkich rekordów?

Rozumiejąc, jak yielddziała słowo kluczowe, natknąłem się na link1 i link2 na StackOverflow, który zaleca korzystanie z yield returniteracji nad DataReaderem i odpowiada to również moim potrzebom. Ale zastanawiam się, co się stanie, jeśli użyję, yield returnjak pokazano poniżej i jeśli nie wykonam iteracji przez cały DataReader, czy połączenie DB pozostanie otwarte na zawsze?

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

Próbowałem tego samego przykładu w przykładowej aplikacji konsolowej i zauważyłem podczas debugowania, że ​​ostatecznie blok GetRecords()nie jest wykonywany. Jak mogę wtedy zapewnić zamknięcie połączenia DB? Czy istnieje lepszy sposób niż użycie yieldsłowa kluczowego? Próbuję zaprojektować niestandardową klasę, która będzie odpowiedzialna za wykonywanie wybranych instrukcji SQL i procedur składowanych w bazie danych i zwróci wynik. Ale nie chcę zwracać DataReader do dzwoniącego. Chcę również upewnić się, że połączenie zostanie zamknięte we wszystkich scenariuszach.

Edytuj Zmieniono odpowiedź na odpowiedź Bena, ponieważ niepoprawne jest oczekiwanie, że osoby wywołujące metodę będą używać tej metody poprawnie, a w odniesieniu do połączenia z DB będzie ona droższa, jeśli metoda zostanie wywołana wiele razy bez powodu.

Dzięki Jakob i Ben za szczegółowe wyjaśnienia.

Tak, napotkasz opisany problem: dopóki nie zakończysz iteracji wyniku, połączenie pozostanie otwarte. Są dwa ogólne podejścia, które mogę wymyślić, aby sobie z tym poradzić:

Pchaj, nie ciągnij

Obecnie zwracasz IEnumerable<IDataRecord>strukturę danych, z której możesz pobrać. Zamiast tego możesz zmienić metodę, aby wypchnąć jej wyniki. Najprostszym sposobem byłoby przekazanie polecenia, Action<IDataRecord>które jest wywoływane przy każdej iteracji:

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

Pamiętaj, że biorąc pod uwagę, że masz do czynienia z kolekcją elementów, IObservable/ IObservermoże być nieco bardziej odpowiednią strukturą danych, ale jeśli nie jest to potrzebne, prosta Actionjest znacznie prostsza .

Chętnie oceniaj

Alternatywą jest upewnienie się, że iteracja całkowicie się zakończyła przed powrotem.

Zwykle możesz to zrobić, po prostu umieszczając wyniki na liście, a następnie zwracając je, ale w tym przypadku istnieje dodatkowa komplikacja każdego elementu będącego tym samym odwołaniem do czytelnika. Potrzebujesz więc czegoś, co wyodrębni wynik z czytnika:

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

Twój finallyblok zawsze będzie wykonywany.

Podczas korzystania yield returnz kompilatora utworzy nową klasę zagnieżdżoną do implementacji automatu stanów.

Ta klasa będzie zawierać cały kod z finallybloków jako osobne metody. Będzie śledził finallybloki, które należy wykonać w zależności od stanu. Wszystkie niezbędne finallybloki zostaną wykonane Disposemetodą.

Zgodnie ze specyfikacją języka C # foreach (V v in x) embedded-statementjest rozszerzony do

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

więc moduł wyliczający zostanie usunięty, nawet jeśli wyjdziesz z pętli za pomocą breaklub return.

Aby uzyskać więcej informacji na temat implementacji iteratora, przeczytaj ten artykuł Jon Skeet

Edytować

Problem z takim podejściem polega na tym, że polegasz na klientach swojej klasy, aby prawidłowo używać metody. Mogliby na przykład pobrać moduł wyliczający bezpośrednio i iterować go w whilepętli bez usuwania go.

Powinieneś rozważyć jedno z rozwiązań sugerowanych przez @BenAaronson.

Niezależnie od określonego yieldzachowania, kod zawiera ścieżki wykonania, które nie będą poprawnie pozbywały się zasobów. Co się stanie, jeśli druga linia zgłosi wyjątek lub trzecią? A nawet twój czwarty? Będziesz potrzebować bardzo złożonego łańcucha try / wreszcie lub możesz użyć usingbloków.

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

Ludzie zauważyli, że nie jest to intuicyjne, że osoby wywołujące twoją metodę mogą nie wiedzieć, że dwukrotne wyliczenie wyniku wywoła metodę dwukrotnie. Cóż, pech. Tak działa ten język. To jest sygnał, żeIEnumerable<T> wysyła. Istnieje powód, dla którego nie zwraca List<T>lub T[]. Ludzie, którzy nie wiedzą o tym, muszą się kształcić, a nie pracować.

Visual Studio ma funkcję o nazwie statyczna analiza kodu. Możesz go użyć, aby sprawdzić, czy prawidłowo zutylizowałeś zasoby.

To, co zrobiłeś, wydaje się złe, ale zadziała dobrze.

Powinieneś użyć IEnumerator <> , ponieważ dziedziczy on także IDisposable .

Ale ponieważ używasz foreach, kompilator nadal używa IDisposable do generowania IEnumerator <> dla foreach.

w rzeczywistości Foreach zawiera wiele rzeczy wewnętrznych.

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