A lambda that compiles to a delegate is executable code. A lambda that compiles to an Expression<TDelegate> is a data structure you can read — and that one distinction is how EF Core turns C# into SQL.

Back in Intermediate lesson 145, you wrote something like context.Products.Where(p => p.Price > 100) against an EF Core DbSet<Product>, and it produced a SQL WHERE clause against a real database — not C# code running row-by-row in your process. Did you ever stop to ask how? p => p.Price > 100 is a lambda. Lambdas compile to IL. EF Core can't execute your process's IL against a SQL Server or PostgreSQL database — there's no way to "run" a compiled method on a database engine.

So EF Core doesn't run your lambda at all. It reads it — as data, inspecting its structure, and generates SQL from what it finds. The mechanism that makes a lambda readable as data, instead of only runnable as code, is an expression tree. It's a genuinely new idea, distinct from everything else in this module: up to now, every lambda you've written has become a delegate. This lesson is about the other thing a lambda can become.

By the end, you'll be able to build and inspect a small expression tree by hand, and you'll understand exactly what EF Core is doing every time you write a LINQ query against a database.

What Is It?

The Simple Explanation

An expression tree is a way of representing a small piece of C# code — usually a lambda — not as compiled, runnable instructions, but as a tree of ordinary .NET objects that describe the code's structure: "this is a comparison," "the left side is a property access," "the right side is a constant, 100." Because it's just a tree of objects, you can walk it, inspect it, print it, or even translate it into an entirely different language — like SQL.

The Technical Definition

An expression tree is built from types in the System.Linq.Expressions namespace, all ultimately deriving from the abstract base class System.Linq.Expressions.Expression. Common concrete node types include BinaryExpression (e.g. a > b), MethodCallExpression (e.g. obj.Method(args)), MemberExpression (e.g. p.Price), ConstantExpression (a literal value), and ParameterExpression (a lambda's parameter, like p). A lambda that gets turned into this kind of tree, as a whole, is represented by Expression<TDelegate> — a generic wrapper holding the tree's root, typed by the delegate signature the lambda matches.

The single most important fact in this entire lesson: whether a lambda becomes a delegate or an expression tree depends entirely on what type the compiler is targeting it against — nothing about the lambda's own syntax changes.

Func<int, bool> asDelegate   = x => x > 5;   // compiled to IL — a runnable delegate
Expression<Func<int, bool>> asTree = x => x > 5;   // compiled to DATA — an object graph describing "x > 5"

Identical lambda syntax on the right-hand side. Completely different compiler output, because the left-hand side's declared type is different.

Why Does It Exist?

The Problem — A Delegate Can Only Be Run, Never Read

Once a lambda is compiled to IL and wrapped in a delegate, its "meaning" is effectively locked away. You can call it and observe its output, but there is no supported way to ask a Func<int, bool> instance "what comparison are you actually performing, and against what value?" That information existed in the compiler for a moment, at compile time — and then it's gone, flattened into opaque, runnable instructions.

This is a serious problem for any library that needs to translate C# logic into a completely different execution environment. EF Core's whole job is turning Where(p => p.Price > 100) into WHERE Price > 100 in SQL — but SQL Server has no idea what .NET IL is, and can't execute it. If Where only ever received a compiled delegate, EF Core would be stuck: its only option would be to pull every row back into memory and filter with C# — which is exactly the "load everything, then filter in memory" anti-pattern that makes database queries slow.

The Solution — Give the Library the Structure, Not Just the Behavior

Expression trees solve this by giving the compiler a second, entirely different way to represent the exact same lambda syntax: instead of "compile this down to something runnable," the compiler is told "build me an object graph describing this code's shape." A library like EF Core's LINQ provider receives that object graph, walks it node by node — "this is a member access on Price," "this is a greater-than comparison," "this is the constant 100" — and generates the equivalent SQL text itself. Your C# lambda was never executed by the CLR at all; it was only ever read.

Big Picture

How It Works

Expression<Func<int, bool>> expr = x => x > 5;

ParameterExpression param = expr.Parameters[0]; // "x"
BinaryExpression body = (BinaryExpression)expr.Body; // "x > 5"
Console.WriteLine(body.NodeType);  // GreaterThan
Console.WriteLine(body.Left);      // x
Console.WriteLine(body.Right);     // 5

Func<int, bool> compiled = expr.Compile();
Console.WriteLine(compiled(10)); // True — NOW it's actually running as code

Simple Example

using System;
using System.Linq.Expressions;

class Program
{
    static void Main()
    {
        // Target type is Expression>, NOT Func —
        // this line does not produce a runnable delegate at all.
        Expression<Func<int, bool>> expr = x => x > 5;

        // Inspect the tree — reading the code as data
        Console.WriteLine($"Parameter: {expr.Parameters[0].Name}");      // x
        Console.WriteLine($"Body: {expr.Body}");                          // (x > 5)

        var comparison = (BinaryExpression)expr.Body;
        Console.WriteLine($"Operator: {comparison.NodeType}");           // GreaterThan
        Console.WriteLine($"Left side: {comparison.Left}");              // x
        Console.WriteLine($"Right side: {comparison.Right}");            // 5

        // Turn the tree BACK into runnable code, only when we actually need to execute it
        Func<int, bool> isGreaterThanFive = expr.Compile();
        Console.WriteLine(isGreaterThanFive(10)); // True
        Console.WriteLine(isGreaterThanFive(2));  // False
    }
}

Code → Meaning → Result: Nothing about x > 5 ever ran as compiled C# until the explicit call to expr.Compile(). Before that, expr was purely a description — an object graph you could print, take apart, and reason about, the same way you'd inspect any other data structure. That's the entire idea, distilled to its smallest possible example.

Real-World Example

Recall the EF Core query from Intermediate lesson 145:

var expensiveProducts = context.Products
    .Where(p => p.Price > 100)
    .ToList();

You now have the vocabulary to explain exactly what happens here. context.Products is an IQueryable<Product> — and IQueryable<T>'s Where extension method has a signature that expects an expression tree, not a delegate:

// The IQueryable version of Where (simplified):
public static IQueryable<T> Where<T>(
    this IQueryable<T> source,
    Expression<Func<T, bool>> predicate); // an EXPRESSION TREE, not a Func

// Compare to the IEnumerable version (LINQ-to-Objects), which you already know:
public static IEnumerable<T> Where<T>(
    this IEnumerable<T> source,
    Func<T, bool> predicate); // an ordinary DELEGATE

Because p => p.Price > 100 is being passed to the Expression<Func<T,bool>> overload, the compiler builds a tree — a MemberExpression for p.Price, a ConstantExpression for 100, wrapped in a BinaryExpression for >. EF Core's query provider walks that exact tree, recognizes each node, and produces:

SELECT [p].[Id], [p].[Name], [p].[Price]
FROM [Products] AS [p]
WHERE [p].[Price] > 100

Your lambda's C# was never executed by your application — it was read once, as data, and translated. This is also exactly why calling an arbitrary C# method (something the provider doesn't recognize how to translate) inside an EF Core Where lambda often throws at query time: the provider walked the tree, hit a node it doesn't know how to turn into SQL, and had nothing left to do but fail. It's not "EF Core can't run your code" — it deliberately never tries to.

Analogy

Under the Hood

ParameterExpression x = Expression.Parameter(typeof(int), "x");
ConstantExpression five = Expression.Constant(5);
BinaryExpression comparison = Expression.GreaterThan(x, five);
Expression<Func<int, bool>> expr =
    Expression.Lambda<Func<int, bool>>(comparison, x);

Common Confusion

1. "Expression<Func<T,bool>> IS a Func<T,bool>" — it isn't, until you compile it

These are two distinct, unrelated types. Expression<Func<int,bool>> cannot be invoked with expr(5) — there is no Invoke on it in the way there is on a delegate. You must explicitly call .Compile() to get back an actual Func<int,bool> before you can call it like a method.

2. "LINQ always translates to SQL" — only IQueryable<T> LINQ does

Where/Select/etc. on an in-memory List<T> or array use the IEnumerable<T> extension methods, which take plain Func delegates and actually execute your C# in-process, exactly like every LINQ example from Intermediate. Only when you're querying an IQueryable<T> source — like an EF Core DbSet<T> — does the expression-tree-based overload kick in and translation happen instead.

3. "Expression trees are a LINQ-only feature" — they're a general-purpose mechanism LINQ happens to use heavily

The System.Linq.Expressions namespace predates and exists independently of any specific LINQ provider. Anything that needs to inspect, generate, cache, or dynamically build C#-shaped logic at runtime — some serialization libraries, mocking frameworks, and rules engines — can and does use expression trees directly, with no LINQ query in sight.

Common Mistakes

Mistake 1 — Calling a C# method EF Core can't translate, inside a query

context.Products.Where(p => SomeComplexCSharpHelper(p)) — if EF Core's provider doesn't recognize SomeComplexCSharpHelper as something it can turn into SQL, the query throws (or in older EF versions, silently evaluated client-side, which quietly fetches far more data than intended).

Keep the logic inside a query expression tree to what the provider can translate — simple property access, comparisons, and the handful of methods (like string.Contains) EF Core specifically knows how to map to SQL. Do custom C#-only logic after materializing results with .ToList(), once you're back to working with plain objects in memory.

Mistake 2 — Calling .Compile() repeatedly on the same expression tree in a hot path

Rebuilding the same Expression<Func<...>> and calling .Compile() on it inside a loop or on every request — each call regenerates IL from scratch, which is meaningfully slower than a single cached delegate call.

Compile once, cache the resulting delegate (a static readonly field, for example), and reuse it — the same instinct as caching any other expensive-to-construct object.

Mistake 3 — Assuming every lambda syntax works as an expression tree

Trying to assign a lambda with a multi-statement block body — Expression<Func<int,int>> f = x => { var y = x + 1; return y * 2; }; — and being surprised it doesn't compile.

Expression trees are restricted to single-expression lambda bodies. If you need multi-statement logic, you need a plain delegate (Func/Action), not an expression tree — the two aren't always interchangeable just because the syntax looks similar.

When Should I Use It?

• You'll encounter expression trees constantly without writing them by hand — every time you write a LINQ query against an EF Core DbSet<T>, you're producing one.
• You'll write expression tree code directly if you're building your own LINQ provider, a dynamic query builder, a mocking/rules framework, or any tool that needs to inspect or translate C#-shaped logic rather than just run it.
• Accept an Expression<Func<T,bool>> parameter (instead of a plain Func<T,bool>) in your own API only when callers genuinely need that logic to be inspectable/translatable — for ordinary in-process filtering, a plain Func is simpler and has none of the single-expression restriction.
• Skip expression trees entirely for everyday application code — you'll consume them (via EF Core) far more often than you construct them yourself.

Mental Model

Key Takeaway

Check Your Understanding

You've seen how a lambda becomes inspectable data instead of runnable code, and exactly how EF Core relies on that. Let's confirm it's solid.

You now know exactly what happens between writing p => p.Price > 100 and seeing a WHERE clause hit your database. Next: the compiler's other lambda trick — how it turns a capturing lambda into a hidden class, and when a lambda allocates at all.

dotnetmadeeasy.com — Learn C# and .NET, the right way.