Return IEnumerable vs. IQueryable

Najlepsza odpowiedź jest dobra, ale nie wspomina o drzewach wyrażeń, które wyjaśniają "jak" oba interfejsy się różnią. Zasadniczo istnieją dwa identyczne zestawy rozszerzeń LINQ. Where(), Sum(), Count(), FirstOrDefault(), etc wszystkie mają dwie wersje: jedną akceptującą funkcje i drugą akceptującą wyrażenia.

• Sygnatura wersji IEnumerable jest: Where(Func<Customer, bool> predicate)

• Sygnatura wersji IQueryable jest: Where(Expression<Func<Customer, bool>> predicate)

Prawdopodobnie używałeś obu tych bez ponieważ oba są wywoływane przy użyciu identycznej składni:

Np. Where(x => x.City == "<City>") działa zarówno na IEnumerable jak i IQueryable

• W przypadku użycia Where() Na kolekcji IEnumerable kompilator przekazuje skompilowaną funkcję do Where()

• Podczas używania Where() Na kolekcji IQueryable kompilator przekazuje drzewo wyrażeń do Where(). Drzewo wyrażeń jest jak system odbicia, ale dla kodu. Kompilator konwertuje kod do struktury danych, która opisuje, co robi kod w formacie łatwo przyswajalnym.

Po co zawracać sobie głowę tym drzewem ekspresji? Chcę tylko Where() filtrować moje dane. Głównym powodem jest to, że zarówno EF, jak i Linq2SQL ORMs mogą konwertować drzewa wyrażeń bezpośrednio do SQL, gdzie kod będzie wykonywany znacznie szybciej.

Oh, to brzmi jak darmowe zwiększenie wydajności, czy powinienem używać AsQueryable() wszędzie w tym przypadku? Nie, IQueryable jest przydatna tylko wtedy, gdy podstawowy dostawca danych może coś zrobić z nim. Konwersja czegoś w rodzaju zwykłego List na IQueryable nie da ci żadnej korzyści.

Tak, obie stosują odroczoną egzekucję. Zilustrujmy różnicę używając SQL Server profiler....

Gdy uruchamiamy następujący kod:

MarketDevEntities db = new MarketDevEntities();

IEnumerable<WebLog> first = db.WebLogs;
var second = first.Where(c => c.DurationSeconds > 10);
var third = second.Where(c => c.WebLogID > 100);
var result = third.Where(c => c.EmailAddress.Length > 11);

Console.Write(result.First().UserName);

W SQL Server profiler znajdujemy polecenie równe:

"SELECT * FROM [dbo].[WebLog]"

Uruchomienie tego bloku kodu z tabelą Weblogu, która ma 1 milion rekordów, zajmuje około 90 sekund.

Tak więc wszystkie rekordy tabeli są ładowane do pamięci jako obiekty, a następnie z każdym .Gdzie () będzie kolejnym filtrem w pamięci przeciwko tym obiektów.

Kiedy używamy IQueryable zamiast IEnumerable w powyższym przykładzie (druga linia):

W SQL Server profiler znajdujemy polecenie równe:

"SELECT TOP 1 * FROM [dbo].[WebLog] WHERE [DurationSeconds] > 10 AND [WebLogID] > 100 AND LEN([EmailAddress]) > 11"

Uruchomienie tego bloku kodu za pomocą IQueryable zajmuje około czterech sekund.

IQueryable ma właściwość o nazwie Expression, która przechowuje wyrażenie drzewa, które zaczyna być tworzone, gdy użyliśmy result w naszym przykładzie (który nazywa się deferred execution), a na końcu to wyrażenie zostanie przekonwertowane do zapytania SQL do uruchom silnik bazy danych.

Oba dadzą ci odroczoną egzekucję, tak.

Co do tego, które jest preferowane w stosunku do innych, zależy od tego, jakie jest twoje bazowe źródło danych.

Zwrócenie liczby mnogiej automatycznie wymusi użycie LINQ do obiektów do odpytywania kolekcji.

Zwracanie IQueryable (który implementuje IEnumerable, nawiasem mówiąc) zapewnia dodatkową funkcjonalność, aby przetłumaczyć zapytanie na coś, co może działać lepiej na źródle bazowym (LINQ do SQL, LINQ do XML, itp.).

Ogólnie chcesz zachować oryginalny statyczny typ zapytania, dopóki nie będzie miało to znaczenia.

Z tego powodu możesz zdefiniować zmienną jako ' var ' zamiast IQueryable<> LUB {[1] } i będziesz wiedział,że nie zmieniasz typu.

Jeśli zaczynasz od IQueryable<>, zazwyczaj chcesz zachować go jako IQueryable<>, dopóki nie będzie jakiegoś ważnego powodu, aby go zmienić. Powodem tego jest to, że chcesz przekazać procesorowi zapytań jak najwięcej informacji. Na na przykład, jeśli zamierzasz używać tylko 10 wyników (wywołałeś Take(10)), chcesz, aby SQL Server wiedział o tym, aby mógł zoptymalizować swoje plany zapytań i wysłać Ci tylko dane, których użyjesz.

Istotnym powodem zmiany typu z IQueryable<> na IEnumerable<> może być to, że wywołujesz jakąś funkcję rozszerzenia, której implementacja IQueryable<> w danym obiekcie albo nie jest w stanie obsłużyć, albo obsługuje nieefektywnie. W takim przypadku możesz chcieć przekonwertować typ na IEnumerable<> (przypisując do zmiennej typu IEnumerable<> lub używając na przykład metody rozszerzenia AsEnumerable) tak, aby wywołane funkcje rozszerzenia były tymi w klasie Enumerable zamiast klasy Queryable.

Ogólnie polecam:

Aby zwrócić IQueryable jeśli chcesz, aby programista za pomocą swojej metody doprecyzował zwracane zapytanie przed wykonaniem.

Jeśli chcesz przetransportować tylko zbiór obiektów do wyliczenia, po prostu weź IEnumerable.

Wyobraź sobie IQueryable jako to, co to jest, "Zapytanie" o dane (które możesz udoskonalić, jeśli chcesz)

IEnumerable to zbiór obiektów (które zostały już odebrane lub został utworzony), nad którym można wyliczyć.

Wiele już zostało powiedziane, ale powrót do korzeni, w bardziej techniczny sposób: {]}

1. IEnumerable jest zbiorem obiektów w pamięci, które można wyliczyć - Sekwencja w pamięci, która umożliwia iterację (ułatwia to Korzystanie z pętli foreach, chociaż można ją używać tylko IEnumerator). Pozostają w pamięci tak, jak jest.
2. IQueryable jest drzewem wyrażeń , które w pewnym momencie zostaną przetłumaczone na coś innego z możliwością wylicz wynik końcowy . Myślę, że to jest to, co myli większość ludzi.

Mają oczywiście różne konotacje.

IQueryable reprezentuje drzewo wyrażeń (po prostu zapytanie), które zostanie przetłumaczone na coś innego przez podstawowego dostawcę zapytań, gdy tylko wywołane zostaną interfejsy API release, takie jak funkcje agregujące LINQ (suma, Liczba itp.) lub ToList[tablica, Słownik,...]. Oraz IQueryable obiekty realizują również IEnumerable, IEnumerable<T> tak, że jeśli reprezentują zapytanie wynik tego zapytania może zostać powtórzony. To znaczy, że nie muszę być tylko zapytaniami. Właściwym określeniem jest to, że są to drzewa ekspresji.

Teraz to, jak te wyrażenia są wykonywane i do czego się zwracają, zależy od tak zwanych dostawców zapytań(executorów wyrażeń, o których możemy myśleć).

W Entity Framework world (czyli dostawca źródeł danych lub dostawca zapytań) IQueryable wyrażenia są tłumaczone do natywnych zapytań T-SQL. Robi z nimi podobne rzeczy. Możesz napisać swój własny zgodnie z koncepcjami dość dobrze opisanymi w LINQ: budowanie łącza IQueryable Provider , na przykład, i możesz chcieć mieć niestandardowe API zapytań dla usługi dostawcy sklepu z produktami.

Więc zasadniczo, IQueryable obiekty są konstruowane przez cały czas, dopóki nie zwolnimy ich i nie powiemy systemowi, aby przepisał je do SQL lub cokolwiek innego i wysłał w dół łańcuch realizacji do dalszego przetwarzania.

Jakby odroczony wykonanie jest to funkcja LINQ, która przechowuje schemat drzewa wyrażeń w pamięci i wysyła go do wykonania tylko na żądanie, za każdym razem, gdy niektóre API są wywoływane przeciwko sekwencji (ten sam Count, ToList, itp.).

Właściwe użycie obu zależy w dużej mierze od zadań, przed którymi stoisz w konkretnym przypadku. Dla dobrze znanego wzorca repozytorium osobiście decyduję się na zwrócenie IList, czyli IEnumerable nad listami (indekserami i tym podobnymi). Dlatego radzę używać IQueryable tylko w repozytoriach, a nie gdziekolwiek indziej w kodzie. Nie mówienie o problemach testowalności, które IQueryable psują i psujązasadę rozdzielania obaw . Jeśli zwrócisz wyrażenie z repozytoriów, konsumenci mogą bawić się warstwą trwałości tak, jak sobie tego życzą.

Mały dodatek do bałaganu :) (z dyskusji w komentarzach)) Żaden z nich nie jest obiekty w pamięci ponieważ nie są prawdziwymi typami per se, są znacznikami typu-jeśli chcesz iść tak głęboko. Ale to ma sens (i dlatego nawet MSDN ująć to w ten sposób) myśleć o IEnumerables jako kolekcjach w pamięci, podczas gdy IQueryables jako drzewach ekspresji. Chodzi o to, że interfejs IQueryable dziedziczy interfejs IEnumerable tak, że jeśli reprezentuje zapytanie, wyniki tego zapytania mogą być wyliczane. Wyliczenie powoduje, że drzewo wyrażeń związane z IQueryable object to be executed. Więc, w rzeczywistości, nie można tak naprawdę wywołać żadnego IEnumerable członka bez posiadania obiektu w pamięci. Dostanie się tam, jeśli to zrobisz, jeśli nie będzie pusta. IQueryables to tylko zapytania, Nie DANE.

Jest post na blogu z krótką próbką kodu źródłowego o tym, jak niewłaściwe użycie {[2] } może dramatycznie wpłynąć na wydajność zapytań LINQ: Entity Framework: IQueryable vs.IEnumerable.

Jeśli kopiemy głębiej i przyjrzymy się źródłom, możemy zobaczyć, że istnieją oczywiście różne metody rozszerzenia dla IEnumerable<T>:

// Type: System.Linq.Enumerable
// Assembly: System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// Assembly location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Core.dll
public static class Enumerable
{
    public static IEnumerable<TSource> Where<TSource>(
        this IEnumerable<TSource> source, 
        Func<TSource, bool> predicate)
    {
        return (IEnumerable<TSource>) 
            new Enumerable.WhereEnumerableIterator<TSource>(source, predicate);
    }
}

I IQueryable<T>:

// Type: System.Linq.Queryable
// Assembly: System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// Assembly location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Core.dll
public static class Queryable
{
    public static IQueryable<TSource> Where<TSource>(
        this IQueryable<TSource> source, 
        Expression<Func<TSource, bool>> predicate)
    {
        return source.Provider.CreateQuery<TSource>(
            Expression.Call(
                null, 
                ((MethodInfo) MethodBase.GetCurrentMethod()).MakeGenericMethod(
                    new Type[] { typeof(TSource) }), 
                    new Expression[] 
                        { source.Expression, Expression.Quote(predicate) }));
    }
}

Pierwszy zwraca iterator enumerable, a drugi tworzy zapytanie za pośrednictwem Dostawcy zapytań, określonego w Źródło.

Ostatnio natknąłem się na problem z Zastosowany algorytm najpierw wykonał zapytanie IQueryable w celu uzyskania zestawu wyników. Następnie zostały one przekazane do pętli foreach, z elementami utworzonymi jako klasa EF. Ta klasa EF została następnie użyta w klauzuli from w zapytaniu Linq do encji, powodując, że wynik jest liczbą. Jestem całkiem nowy w EF i Linq dla podmiotów, więc zajęło trochę czasu, aby dowiedzieć się, co było wąskim gardłem. Korzystając z Miniprofilingu znalazłem zapytanie i następnie przekonwertowano wszystkie poszczególne operacje na pojedyncze IQueryable Linq dla zapytań encji. Wykonanie IQueryable zajęło 15 sekund, a IQueryable 0,5 sekundy. Były trzy tabele zaangażowane i, po przeczytaniu tego, uważam, że IEnumerable zapytanie było faktycznie tworząc trzy tabela cross-produkt i filtrowanie wyników.

Spróbuj użyć IQueryables jako zasady kciuka i profiluj swoją pracę, aby twoje zmiany były wymierne.

Chciałbym wyjaśnić kilka rzeczy ze względu na pozornie sprzeczne odpowiedzi (głównie wokół IEnumerable).

(1) IQueryable rozszerza interfejs IEnumerable. (Możesz wysłać IQueryable do czegoś, co oczekuje IEnumerable bez błędu.)

(2) zarówno IQueryable jak i IEnumerable LINQ próbują leniwie ładować podczas iteracji nad zestawem wyników. (Zauważ, że implementację można zobaczyć w metodach rozszerzenia interfejsu dla każdego typu.)

Innymi słowy, IEnumerables nie są wyłącznie "pamięcią". IQueryables nie zawsze są wykonywane w bazie danych. IEnumerable musi ładować rzeczy do pamięci (po pobraniu, być może leniwie), ponieważ nie ma abstrakcyjnego dostawcy danych. IQueryables polegaj na abstrakcyjnym dostawcy (takim jak LINQ-to-SQL), chociaż może to być również dostawca.NET w pamięci.

Przykładowy przypadek użycia

(A) pobiera listę rekordów jako IQueryable z kontekstu EF. (Brak zapisów w pamięci.)

(b) przekazuje IQueryable do widoku, którego modelem jest IEnumerable. (Valid. IQueryable extends IEnumerable.)

(C) iteracja i dostęp do rekordów, elementów potomnych i właściwości zestawu danych z widoku. (Może powodować wyjątki!)

Możliwe Problemy

(1) IEnumerable próbuje leniwie załadować i kontekst danych jest wygasły. Wyjątek odrzucony, ponieważ dostawca nie jest już dostępny.

(2) Entity Framework entity proxy są włączone (domyślnie) i próbujesz uzyskać dostęp do powiązanego (Wirtualnego) obiektu z wygasłym kontekstem danych. Tak samo jak (1).

(3) wiele aktywnych zestawów wyników (MARS). Jeśli iterujesz nad IEnumerable w bloku foreach( var record in resultSet ) i jednocześnie próbujesz uzyskać dostęp record.childEntity.childProperty, możesz skończyć z Marsem z powodu leniwego ładowania zarówno zbioru danych, jak i jednostki relacyjnej. Spowoduje to wyjątek, jeśli nie jest on włączony w ciągu połączenia.

Rozwiązanie

• odkryłem, że włączenie Marsa w łańcuchu połączeń działa zawodnie. Proponuję unikać Marsa, chyba że jest dobrze zrozumiane i wyraźnie pożądane.

Wykonaj zapytanie i zapisz wyniki, wywołując resultList = resultSet.ToList() to wydaje się być najprostszym sposobem zapewnienia, że Twoje jednostki są w pamięci.

W przypadkach, gdy uzyskujesz dostęp do podmiotów powiązanych, nadal możesz wymagać kontekstu danych. Albo To, albo możesz wyłączyć proxy encji i jawnie Include powiązane podmioty z DbSet.

Główna różnica pomiędzy "IEnumerable" i "IQueryable" Dotyczy miejsca, w którym zostanie wykonana logika filtra. Jeden wykonuje po stronie klienta (w pamięci), a drugi wykonuje w bazie danych.

Na przykład, możemy rozważyć przykład, gdzie mamy 10,000 rekordów dla użytkownika w naszej bazie danych i powiedzmy tylko 900 z których są aktywnymi użytkownikami, więc w tym przypadku jeśli użyjemy "IEnumerable", to najpierw załaduje on wszystkie 10,000 rekordów w pamięci, a następnie zastosuje filtr IsActive, który ostatecznie zwraca 900 aktywnych użytkowników.

Podczas gdy z drugiej strony w tym samym przypadku, jeśli użyjemy "IQueryable", bezpośrednio zastosujemy filtr IsActive w bazie danych, który bezpośrednio stamtąd zwróci 900 aktywnych użytkowników.

Reference Link

Są to pewne różnice między IQueryable<T> i IEnumerable<T>

Możemy używać obu w ten sam sposób, a różnią się one tylko w wydajności.

IQueryable wykonuje tylko z bazą danych w efektywny sposób. Oznacza to, że tworzy całe zapytanie select i pobiera tylko powiązane rekordy.

Na przykład, chcemy wziąć Top 10 klientów, których nazwa zaczyna się od "Nimal". W tym przypadku zapytanie select zostanie wygenerowane jako select top 10 * from Customer where name like ‘Nimal%’.

Ale gdybyśmy użyli IEnumerable, zapytanie byłoby jak select * from Customer where name like ‘Nimal%’ i pierwsza dziesiątka będzie filtrowany na poziomie kodowania C# (pobiera wszystkie rekordy klienta z bazy danych i przekazuje je do C#).

Oprócz pierwszych 2 naprawdę dobrych odpowiedzi (by driis & by Jacob):

IEnumerable interfejs jest w systemie.Przestrzeń nazw kolekcji.

The IEnumerable object reprezentuje zbiór danych w pamięci i może poruszać się po tych danych tylko do przodu. Zapytanie reprezentowane przez obiekt IEnumerable jest wykonywane natychmiast i całkowicie, dzięki czemu aplikacja szybko otrzymuje dane.

Gdy zapytanie zostanie wykonane, IEnumerable wczytuje wszystkie dane, a jeśli musimy filtrować to samo filtrowanie odbywa się po stronie klienta.

Interfejs IQueryable znajduje się w systemie.Przestrzeń nazw Linq.

Obiekt IQueryable zapewnia zdalny dostęp do bazy danych i umożliwia nawigowanie po danych w bezpośredniej kolejności od początku do końca lub w odwrotnej kolejności. W procesie tworzenia zapytania zwracany obiekt jest IQueryable, zapytanie jest zoptymalizowane. W rezultacie podczas jego wykonywania zużywa się mniej pamięci, mniej sieci przepustowość, ale jednocześnie może być przetwarzana nieco wolniej niż zapytanie, które zwraca obiekt liczbowy.

Co wybrać?

Jeśli potrzebujesz całego zestawu zwracanych danych, lepiej jest użyć IEnumerable, który zapewnia maksymalną prędkość.

Jeśli nie potrzebujesz całego zestawu zwracanych danych, a tylko niektórych przefiltrowanych danych, lepiej jest użyć IQueryable.

Podczas używania LINQ do encji, ważne jest, aby zrozumieć, kiedy aby użyć liczby mnogiej i liczby mnogiej. Jeśli użyjemy IEnumerable, zapytanie zostanie wykonane natychmiast. Jeśli użyjemy IQueryable, wykonanie zapytania zostanie odroczone do momentu, gdy aplikacja zażąda wyliczenie. Teraz zobaczmy, co należy wziąć pod uwagę przy podejmowaniu decyzji, czy użyj IQueryable lub IEnumerable. Korzystanie z IQueryable daje możliwość utworzenia złożonego zapytania LINQ przy użyciu wielu instrukcji bez wykonywania zapytania w poziom bazy danych. Zapytanie dostaje wykonywane tylko wtedy, gdy zostanie wyliczone ostateczne zapytanie LINQ.