La mejor explicación sobre los árboles de expresión que he leído es este artículo de Charlie Calvert.
Para resumirlo;
Un árbol de expresión representa lo que quiere hacer, no cómo quiere hacerlo.
Considere la siguiente expresión lambda muy simple:
Func<int, int, int> function = (a, b) => a + b;
Esta declaración consta de tres secciones:
- Una declaración:
Func<int, int, int> function
- Un operador igual:
=
- Una expresión lambda:
(a, b) => a + b;
La variable functionapunta al código ejecutable sin procesar que sabe cómo sumar dos números .
Esta es la diferencia más importante entre delegados y expresiones. Llamas function(a Func<int, int, int>) sin saber nunca qué hará con los dos enteros que pasaste. Toma dos y devuelve uno, eso es lo máximo que puede saber su código.
En la sección anterior, vio cómo declarar una variable que apunta a un código ejecutable sin procesar. Los árboles de expresión no son código ejecutable , son una forma de estructura de datos.
Ahora, a diferencia de los delegados, su código puede saber qué debe hacer un árbol de expresión.
LINQ proporciona una sintaxis simple para traducir código en una estructura de datos llamada árbol de expresión. El primer paso es agregar una declaración de uso para introducir el Linq.Expressionsespacio de nombres:
using System.Linq.Expressions;
Ahora podemos crear un árbol de expresión:
Expression<Func<int, int, int>> expression = (a, b) => a + b;
La expresión lambda idéntica que se muestra en el ejemplo anterior se convierte en un árbol de expresión declarado de tipo Expression<T>. El identificador expression no es un código ejecutable; es una estructura de datos llamada árbol de expresión.
Eso significa que no puede simplemente invocar un árbol de expresión como podría invocar a un delegado, sino que puede analizarlo. Entonces, ¿qué puede entender su código al analizar la variable expression?
var body = expression.Body;
var parameters = expression.Parameters;
var firstParam = parameters[0];
var secondParam = parameters[1].
Aquí vemos que hay una gran cantidad de información que podemos obtener de una expresión.
Pero, ¿por qué necesitaríamos eso?
Ha aprendido que un árbol de expresión es una estructura de datos que representa código ejecutable. Pero hasta ahora no hemos respondido a la pregunta central de por qué uno querría hacer tal conversión. Esta es la pregunta que hicimos al principio de este artículo, y ahora es el momento de responderla.
Una consulta LINQ to SQL no se ejecuta dentro de su programa C #. En cambio, se traduce a SQL, se envía a través de un cable y se ejecuta en un servidor de base de datos. En otras palabras, el siguiente código nunca se ejecuta realmente dentro de su programa:
var query = from c in db.Customers where c.City == "Nantes" select new { c.City, c.CompanyName };
Primero se traduce a la siguiente declaración SQL y luego se ejecuta en un servidor:
SELECT [t0].[City], [t0].[CompanyName] FROM [dbo].[Customers] AS [t0] WHERE [t0].[City] = @p0
El código que se encuentra en una expresión de consulta debe traducirse en una consulta SQL que se puede enviar a otro proceso como una cadena. En este caso, ese proceso pasa a ser una base de datos de servidor SQL. Obviamente, será mucho más fácil traducir una estructura de datos como un árbol de expresión a SQL que traducir IL sin formato o código ejecutable a SQL. Para exagerar un poco la dificultad del problema, ¡imagínese tratando de traducir una serie de ceros y unos a SQL!
Cuando llega el momento de traducir su expresión de consulta a SQL, el árbol de expresión que representa su consulta se desarma y analiza, tal como desarmamos nuestro árbol de expresión lambda simple en la sección anterior. Por supuesto, el algoritmo para analizar el árbol de expresiones LINQ to SQL es mucho más sofisticado que el que usamos, pero el principio es el mismo. Una vez que ha analizado las partes del árbol de expresión, LINQ las analiza y decide la mejor manera de escribir una declaración SQL que devolverá los datos solicitados.
Los árboles de expresión se crearon para realizar la tarea de convertir código, como una expresión de consulta, en una cadena que se puede pasar a algún otro proceso y ejecutar allí. Es así de simple. No hay un gran misterio aquí, no hay una varita mágica que deba agitarse. Uno simplemente toma el código, lo convierte en datos y luego analiza los datos para encontrar las partes constituyentes que se traducirán en una cadena que se puede pasar a otro proceso.
Debido a que la consulta llega al compilador encapsulada en una estructura de datos tan abstracta, el compilador es libre de interpretarla de la forma que desee. No está obligado a ejecutar la consulta en un orden particular, o de una manera particular. En su lugar, puede analizar el árbol de expresión, descubrir qué desea que se haga y luego decidir cómo hacerlo. Al menos en teoría, tiene la libertad de considerar cualquier número de factores, como el tráfico de red actual, la carga en la base de datos, los conjuntos de resultados actuales que tiene disponibles, etc. En la práctica, LINQ to SQL no considera todos estos factores. , pero en teoría es libre de hacer prácticamente lo que quiera. Además, uno podría pasar este árbol de expresión a algún código personalizado que escriba a mano que podría analizarlo y traducirlo a algo muy diferente de lo que produce LINQ to SQL.
Una vez más, vemos que los árboles de expresión nos permiten representar (¿expresar?) Lo que queremos hacer. Y usamos traductores que deciden cómo se usan nuestras expresiones.