Лучшее объяснение деревьев выражений, которое я когда-либо читал, - это статья Чарли Калверта.
Подвести итог;
Дерево выражений представляет то, что вы хотите сделать, а не то, как вы хотите это делать.
Рассмотрим следующее очень простое лямбда-выражение:
Func<int, int, int> function = (a, b) => a + b;
Это заявление состоит из трех разделов:
- Декларация:
Func<int, int, int> function
- Оператор равенства:
=
- Лямбда-выражение:
(a, b) => a + b;
Переменная functionуказывает на необработанный исполняемый код, который умеет складывать два числа .
Это наиболее важное различие между делегатами и выражениями. Вы вызываете function(a Func<int, int, int>), даже не зная, что он будет делать с двумя переданными вами целыми числами. Он берет два и возвращает один, это все, что может знать ваш код.
В предыдущем разделе вы видели, как объявить переменную, указывающую на необработанный исполняемый код. Деревья выражений - это не исполняемый код , это форма структуры данных.
Теперь, в отличие от делегатов, ваш код может знать, для чего предназначено дерево выражений.
LINQ предоставляет простой синтаксис для преобразования кода в структуру данных, называемую деревом выражений. Первый шаг - добавить оператор using для представления Linq.Expressionsпространства имен:
using System.Linq.Expressions;
Теперь мы можем создать дерево выражений:
Expression<Func<int, int, int>> expression = (a, b) => a + b;
Идентичное лямбда-выражение, показанное в предыдущем примере, преобразуется в дерево выражения, объявленное как имеющее тип Expression<T>. Идентификатор expression не является исполняемым кодом; это структура данных, называемая деревом выражений.
Это означает, что вы не можете просто вызвать дерево выражений, как вы могли бы вызвать делегата, но вы можете проанализировать его. Итак, что может понять ваш код, анализируя переменную expression?
var body = expression.Body;
var parameters = expression.Parameters;
var firstParam = parameters[0];
var secondParam = parameters[1].
Здесь мы видим, что выражение дает нам много информации.
Но зачем нам это нужно?
Вы узнали, что дерево выражений - это структура данных, представляющая исполняемый код. Но до сих пор мы не ответили на главный вопрос, зачем нужно совершать такое преобразование. Это вопрос, который мы задали в начале этого поста, и теперь пора на него ответить.
Запрос LINQ to SQL не выполняется внутри вашей программы C #. Вместо этого он переводится в SQL, отправляется по сети и выполняется на сервере базы данных. Другими словами, следующий код никогда не выполняется внутри вашей программы:
var query = from c in db.Customers where c.City == "Nantes" select new { c.City, c.CompanyName };
Сначала он преобразуется в следующий оператор SQL, а затем выполняется на сервере:
SELECT [t0].[City], [t0].[CompanyName] FROM [dbo].[Customers] AS [t0] WHERE [t0].[City] = @p0
Код, найденный в выражении запроса, должен быть преобразован в запрос SQL, который можно отправить другому процессу в виде строки. В данном случае этим процессом является база данных SQL-сервера. Очевидно, будет намного проще преобразовать структуру данных, такую как дерево выражений, в SQL, чем преобразовать необработанный IL или исполняемый код в SQL. Чтобы несколько преувеличить сложность проблемы, просто представьте, что пытаетесь перевести серию нулей и единиц в SQL!
Когда приходит время перевести выражение вашего запроса в SQL, дерево выражений, представляющее ваш запрос, разбирается и анализируется так же, как мы разобрали наше простое дерево лямбда-выражения в предыдущем разделе. Конечно, алгоритм синтаксического анализа дерева выражений LINQ to SQL намного сложнее, чем тот, который мы использовали, но принцип тот же. После анализа частей дерева выражения LINQ обдумывает их и решает, как лучше всего написать инструкцию SQL, которая вернет запрошенные данные.
Деревья выражений были созданы для решения задачи преобразования кода, такого как выражение запроса, в строку, которую можно передать другому процессу и выполнить там. Это так просто. Здесь нет большой тайны, нет волшебной палочки, которой нужно махать. Нужно просто взять код, преобразовать его в данные, а затем проанализировать данные, чтобы найти составные части, которые будут преобразованы в строку, которую можно передать другому процессу.
Поскольку запрос поступает в компилятор, заключенный в такую абстрактную структуру данных, компилятор может интерпретировать его практически любым способом. Он не обязан выполнять запрос в определенном порядке или определенным образом. Вместо этого он может проанализировать дерево выражений, обнаружить, что вы хотите сделать, а затем решить, как это сделать. По крайней мере теоретически, он может учитывать любое количество факторов, таких как текущий сетевой трафик, нагрузка на базу данных, текущие наборы результатов, которые он имеет, и т. Д. На практике LINQ to SQL не учитывает все эти факторы. , но теоретически он может делать практически все, что хочет. Кроме того, можно передать это дерево выражений в некоторый пользовательский код, который вы пишете вручную, который мог бы проанализировать его и преобразовать во что-то очень отличное от того, что создается LINQ to SQL.
И снова мы видим, что деревья выражений позволяют нам представлять (выражать?) То, что мы хотим сделать. И мы пользуемся услугами переводчиков, которые решают, как наши выражения используются.