Najlepszym wyjaśnieniem drzew ekspresji, jakie kiedykolwiek czytałem, jest ten artykuł Charliego Calverta.
Podsumowując;
Drzewo wyrażeń reprezentuje to , co chcesz zrobić, a nie sposób , w jaki chcesz to zrobić.
Rozważmy następujące bardzo proste wyrażenie lambda:
Func<int, int, int> function = (a, b) => a + b;
To oświadczenie składa się z trzech części:
- Oświadczenie:
Func<int, int, int> function
- Operator równości:
=
- Wyrażenie lambda:
(a, b) => a + b;
Zmienna functionwskazuje na surowy kod wykonywalny, który wie, jak dodać dwie liczby .
To jest najważniejsza różnica między delegatami a wyrażeniami. Wołasz function(a Func<int, int, int>), nigdy nie wiedząc, co zrobi z dwiema podanymi liczbami całkowitymi. Zajmuje dwa i zwraca jeden, czyli najwięcej, co Twój kod może wiedzieć.
W poprzedniej sekcji dowiedziałeś się, jak zadeklarować zmienną wskazującą na surowy kod wykonywalny. Drzewa wyrażeń nie są kodem wykonywalnym , są formą struktury danych.
Teraz, w przeciwieństwie do delegatów, Twój kod może wiedzieć, do czego służy drzewo wyrażeń.
LINQ zapewnia prostą składnię do tłumaczenia kodu na strukturę danych nazywaną drzewem wyrażeń. Pierwszym krokiem jest dodanie instrukcji using w celu wprowadzenia Linq.Expressionsprzestrzeni nazw:
using System.Linq.Expressions;
Teraz możemy stworzyć drzewo wyrażeń:
Expression<Func<int, int, int>> expression = (a, b) => a + b;
Identyczne wyrażenie lambda pokazane w poprzednim przykładzie jest konwertowane na drzewo wyrażenia zadeklarowane jako typu Expression<T>. Identyfikator expression nie jest kodem wykonywalnym; jest to struktura danych zwana drzewem wyrażeń.
Oznacza to, że nie możesz po prostu wywołać drzewa wyrażeń, tak jak można wywołać delegata, ale możesz je przeanalizować. Co więc może zrozumieć Twój kod, analizując zmienną expression?
var body = expression.Body;
var parameters = expression.Parameters;
var firstParam = parameters[0];
var secondParam = parameters[1].
Tutaj widzimy, że jest wiele informacji, które możemy uzyskać z wyrażenia.
Ale po co nam to?
Dowiedziałeś się, że drzewo wyrażeń jest strukturą danych, która reprezentuje wykonywalny kod. Ale jak dotąd nie odpowiedzieliśmy na główne pytanie, dlaczego ktoś miałby chcieć dokonać takiej konwersji. To jest pytanie, które zadaliśmy na początku tego postu i teraz czas na nie odpowiedzieć.
Zapytanie LINQ to SQL nie jest wykonywane w programie C #. Zamiast tego jest tłumaczony na język SQL, przesyłany przez sieć i wykonywany na serwerze bazy danych. Innymi słowy, następujący kod nigdy nie jest wykonywany w twoim programie:
var query = from c in db.Customers where c.City == "Nantes" select new { c.City, c.CompanyName };
Najpierw jest tłumaczony na następującą instrukcję SQL, a następnie wykonywany na serwerze:
SELECT [t0].[City], [t0].[CompanyName] FROM [dbo].[Customers] AS [t0] WHERE [t0].[City] = @p0
Kod znaleziony w wyrażeniu zapytania musi zostać przetłumaczony na zapytanie SQL, które można wysłać do innego procesu jako ciąg. W tym przypadku procesem jest baza danych serwera SQL. Oczywiście znacznie łatwiej będzie przetłumaczyć strukturę danych, taką jak drzewo wyrażeń na SQL, niż przetłumaczyć surowy IL lub kod wykonywalny na SQL. Aby nieco wyolbrzymić trudność problemu, wyobraź sobie, że próbujesz przetłumaczyć serię zer i jedynek na język SQL!
Kiedy nadchodzi czas na przetłumaczenie wyrażenia zapytania na język SQL, drzewo wyrażeń reprezentujące zapytanie jest rozbierane i analizowane, tak jak w poprzedniej sekcji rozebraliśmy nasze proste drzewo wyrażeń lambda. To prawda, algorytm analizowania drzewa wyrażeń LINQ to SQL jest znacznie bardziej wyrafinowany niż ten, którego użyliśmy, ale zasada jest taka sama. Po przeanalizowaniu części drzewa wyrażenia LINQ analizuje je i decyduje o najlepszym sposobie napisania instrukcji SQL, która zwróci żądane dane.
Drzewa wyrażeń zostały utworzone w celu wykonania zadania konwersji kodu, takiego jak wyrażenie zapytania, na ciąg znaków, który można przekazać do innego procesu i tam wykonać. To takie proste. Nie ma tu żadnej wielkiej tajemnicy, żadnej magicznej różdżki, którą trzeba machać. Po prostu bierze się kod, konwertuje go na dane, a następnie analizuje dane w celu znalezienia części składowych, które zostaną przetłumaczone na ciąg, który można przekazać do innego procesu.
Ponieważ zapytanie dociera do kompilatora w takiej abstrakcyjnej strukturze danych, kompilator może je zinterpretować w niemal dowolny sposób. Nie jest zmuszony do wykonania zapytania w określonej kolejności ani w określony sposób. Zamiast tego może przeanalizować drzewo wyrażeń, odkryć, co chcesz zrobić, a następnie zdecydować, jak to zrobić. Przynajmniej w teorii ma swobodę uwzględniania dowolnej liczby czynników, takich jak bieżący ruch w sieci, obciążenie bazy danych, aktualne dostępne zestawy wyników itp. W praktyce LINQ to SQL nie bierze pod uwagę wszystkich tych czynników. , ale teoretycznie może robić prawie wszystko, czego chce. Co więcej, można przekazać to drzewo wyrażeń do jakiegoś niestandardowego kodu, który piszesz ręcznie, który mógłby je przeanalizować i przetłumaczyć na coś bardzo różniącego się od tego, co jest produkowane przez LINQ to SQL.
Po raz kolejny widzimy, że drzewa wyrażeń pozwalają nam przedstawić (wyrazić?) To , co chcemy zrobić. Korzystamy z usług tłumaczy, którzy decydują o tym, jak używane są nasze wyrażenia.