Найкраще пояснення про дерева виразів, яке я коли-небудь читав, - це стаття Чарлі Калверта.
Підсумовуючи це;
Дерево виразів представляє те, що ви хочете зробити, а не те, як ви хочете це зробити.
Розглянемо такий простий лямбда-вираз:
Func<int, int, int> function = (a, b) => a + b;
Це твердження складається з трьох розділів:
- Декларація:
Func<int, int, int> function
- Оператор рівних:
=
- Лямбда-вираз:
(a, b) => a + b;
Змінна functionвказує на вихідний виконуваний код, який знає, як скласти два числа .
Це найважливіша різниця між делегатами та виразами. Ви телефонуєте function(а 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 буде набагато простіше, ніж перекласти необроблений ІЛ чи виконуваний код у SQL. Щоб дещо перебільшити складність проблеми, просто уявіть спробу перевести ряд нулів і одиниць в SQL!
Коли настав час перекласти вираз вашого запиту в SQL, дерево виразів, що представляє ваш запит, розбирається та аналізується, як ми розібрали наше просте дерево лямбда-виразів у попередньому розділі. Звичайно, алгоритм синтаксичного аналізу дерева виразів LINQ до SQL набагато складніший, ніж той, який ми використовували, але принцип той самий. Після аналізу частин дерева виразів LINQ обробляє їх і вирішує найкращий спосіб написати оператор SQL, який поверне запитувані дані.
Дерева виразів були створені для того, щоб зробити завдання перетворення коду, такого як вираз запиту, у рядок, який можна передати якомусь іншому процесу та виконати там. Це так просто. Тут немає великої таємниці, немає чарівної палички, якою потрібно махати. Просто беруть код, перетворюють його в дані, а потім аналізують дані, щоб знайти складові частини, які будуть переведені в рядок, який можна передати іншому процесу.
Оскільки запит надходить до компілятора, інкапсульованого в таку абстрактну структуру даних, компілятор може вільно інтерпретувати його практично будь-яким способом, який він хоче. Він не змушений виконувати запит у певному порядку або певним чином. Натомість він може проаналізувати дерево виразів, виявити, що ви хочете зробити, а потім вирішити, як це зробити. Принаймні теоретично, він має свободу враховувати будь-яку кількість факторів, таких як поточний мережевий трафік, навантаження на базу даних, поточні набори результатів, які вона має в наявності, тощо. На практиці LINQ to SQL не враховує всі ці фактори , але теоретично безкоштовно робити майже те, що він хоче. Крім того, можна передати це дерево виразів якомусь користувацькому коду, який ви пишете від руки, який може проаналізувати його та перевести в щось дуже різне від того, що створюється LINQ to SQL.
Ще раз бачимо, що дерева виразів дозволяють представляти (висловлювати?) Те, що ми хочемо робити. І ми використовуємо перекладачів, які вирішують, як вживаються наші вирази.