Czy są jakieś pułapki związane z używaniem typu IEnumerable <T> dla danych SQL?

Question

Moje pytanie dotyczące statusu połączenia SQL, obciążenia itp na podstawie następującego kodu:

public IEnumberable<MyType> GetMyTypeObjects() 
{ 
    string cmdTxt = "select * from MyObjectTable"; 

    using(SqlConnection conn = new SqlConnection(connString)) 
    { 
    using(SqlCommand cmd = new SqlCommand(cmdTxt, conn)) 
    { 
     conn.Open(); 
     using(SqlDataReader reader = cmd.ExecuteReader()) 
     { 
     while(reader.Read()) 
     { 
      yield return Mapper.MapTo<MyType>(reader); 
     } 
     } 
    } 
    } 
    yield break; 
} 

widzę to może być problemem, jeśli istnieje wiele uruchomione procesy podobny kod z długich czasów wykonania między iteracji obiekt IEnumerable, ponieważ połączenia będą otwierane dłużej, itp. Wydaje się jednak, że może to zmniejszyć użycie procesora na serwerze SQL, ponieważ zwraca dane tylko wtedy, gdy używany jest obiekt IEnumerable. Obniża także użycie pamięci na kliencie, ponieważ klient musi załadować tylko jedną instancję MyType, podczas gdy działa, zamiast ładowania wszystkich wystąpień MyType (przez iterowanie przez cały obiekt DataReader i zwracanie listy lub coś podobnego).

• Czy istnieją przypadki, można myśleć, gdzie nie chcesz używać IEnumerable w ten sposób, czy jakiekolwiek przypadki uważasz, że doskonale pasuje?

• Jaki rodzaj obciążenia to stawia na serwerze SQL?

• Czy jest to coś, co można użyć we własnym kodzie (z wyjątkiem jakiejkolwiek wzmianki o NHibernate, Subsonic, itp.)?

-

Answer 1

Nie użyłbym tego, ponieważ ukrywa to, co się dzieje, i może pozostawić połączenia z bazą danych bez właściwej utylizacji.

Obiekt połączenia zostanie zamknięty po przeczytaniu ostatniego rekordu, a jeśli przerwie czytanie przed tym obiekt połączenia nie zostanie usunięty. Jeśli na przykład wiesz, że zawsze masz dziesięć rekordów w wyniku i po prostu masz pętlę, która odczytuje te dziesięć rekordów z modułu wyliczającego, nie wykonując jedenastego polecenia Odczytaj, które czyta poza ostatnim elementem, połączenie nie jest poprawnie zamknięte. Ponadto, jeśli chcesz użyć tylko części wyniku, nie masz możliwości zamknięcia połączenia bez czytania reszty rekordów.

Nawet zbudowany w rozszerzeń dla rachmistrzów może powodować nawet jeśli seamlingy ich używać prawidłowo:

foreach (MyType item in GetMyTypeObjects().Take(10)) { 
    ... 
} 

Answer 2

Polecam przed wstępną optymalizacją. W wielu sytuacjach połączenia będą łączone.

Nie oczekuję również żadnej różnicy w obciążeniu serwera SQL - zapytanie zostanie już skompilowane i będzie działać.

Answer 3

To nie jest wzór, który powinienem wykonać. Nie martwiłbym się tak bardzo o ładowanie na serwerze, co o blokadach. Podążanie za tym wzorcem integruje proces pobierania danych z przepływem logiki biznesowej i wydaje się, że jest to wszechstronna recepta na kłopoty; nie masz pojęcia, co dzieje się po stronie iteracji, i wkładasz w to siebie. Odzyskaj dane za jednym razem, a następnie zezwól na wyliczenie kodu klienta po zamknięciu czytnika.

Answer 4

Moim problemem jest to, że jesteś oddanie się całkowicie na łasce kodu klienckiego.

Wspomniałeś już, że kod wywołujący może utrzymywać połączenie dłużej otwarte, niż jest to absolutnie konieczne, ale istnieje również możliwość, że nigdy nie pozwoli na zamknięcie/usunięcie obiektów.

Dopóki kod klienta używa foreach, using etc lub wyraźnie wzywa Dispose metodę wyliczający za to jesteś w porządku, ale nie ma nic, aby zatrzymać go robi coś takiego:

var e = GetMyTypeObjects().GetEnumerator(); 
e.MoveNext(); // open the connection etc 

// forget about the enumerator and go away and do something else 
// now the reader, command and connection won't be closed/disposed 
// until the GC kicks in and calls their finalisers