Expression Trees and Func vs Expression

An expression tree is a data structure that represents C# code as a tree of objects — not compiled, executable code, but a description of the code that can be inspected, modified, and translated into something else. EF Core uses expression trees to translate LINQ queries into SQL: when you write .Where(p => p.IsPublished) on a DbSet, EF Core receives an Expression<Func<Post, bool>>, inspects the tree, and generates WHERE IsPublished = 1. This is the mechanism that makes LINQ-to-SQL possible — and understanding it prevents a class of subtle performance bugs.

Func vs Expression #

// ── Func<T, bool> — compiled, executable code (runs in C#) ───────────────
Func<Post, bool> func = p => p.IsPublished && p.ViewCount > 1000;
// This is a delegate: you can call it: func(somePost) → true/false
// EF Core CANNOT inspect what's inside — it receives a black-box function

// ── Expression<Func<T, bool>> — uncompiled code as data ─────────────────
Expression<Func<Post, bool>> expr = p => p.IsPublished && p.ViewCount > 1000;
// This is a data structure representing the lambda
// EF Core CAN inspect it: "parameter p, access IsPublished, AND, access ViewCount, GT, 1000"
// EF Core translates it to SQL: WHERE IsPublished = 1 AND ViewCount > 1000

// ── The difference at the EF Core boundary ────────────────────────────────
IQueryable<Post> query = _db.Posts;

// ✅ Server-side: Where with Expression<> — translated to SQL WHERE clause
var serverFiltered = query.Where(p => p.IsPublished);  // SQL: WHERE IsPublished = 1

// ❌ Client-side: Where on IEnumerable — downloads all rows, filters in C#!
IEnumerable<Post> asEnumerable = query.AsEnumerable();
var clientFiltered = asEnumerable.Where(p => p.IsPublished);  // loads ALL posts first!

Inspecting Expression Trees #

// Expression trees are inspectable objects
Expression<Func<Post, bool>> expr = p => p.IsPublished && p.ViewCount > 1000;

// The tree has nodes:
//   BinaryExpression (AndAlso)
//     Left:  MemberExpression (p.IsPublished)
//     Right: BinaryExpression (GreaterThan)
//              Left:  MemberExpression (p.ViewCount)
//              Right: ConstantExpression (1000)

Console.WriteLine(expr.Body.NodeType);       // AndAlso
Console.WriteLine(expr.Parameters[0].Name); // "p"
Console.WriteLine(expr.ToString());
// "p => (p.IsPublished AndAlso (p.ViewCount > 1000))"

// Compile to a Func (makes the expression executable)
Func<Post, bool> compiled = expr.Compile();
bool result = compiled(new Post { IsPublished = true, ViewCount = 2000 });   // true

The IQueryable vs IEnumerable Trap #

// ── The classic mistake — calling AsEnumerable too early ──────────────────
// ❌ Loads ALL published posts into memory, then paginates in C#
var badQuery = _db.Posts
    .Where(p => p.IsPublished)
    .AsEnumerable()          // ← everything above runs in SQL, everything below in C#
    .Skip(page * pageSize)   // C# pagination — unnecessary memory use
    .Take(pageSize)
    .ToList();

// ✅ Entire operation runs as a single optimised SQL query
var goodQuery = await _db.Posts
    .Where(p => p.IsPublished)
    .OrderByDescending(p => p.CreatedAt)
    .Skip(page * pageSize)   // SQL OFFSET
    .Take(pageSize)          // SQL FETCH NEXT
    .ToListAsync();

Common Mistakes #

Mistake 1 — Passing Func instead of Expression to a repository method #

❌ Wrong — IEnumerable path: loads entire table, filters in C#:

public IEnumerable<Post> Find(Func<Post, bool> predicate)
    => _db.Posts.Where(predicate);   // IEnumerable.Where — client evaluation!

✅ Correct — Expression path: EF Core translates to SQL:

public IQueryable<Post> Find(Expression<Func<Post, bool>> predicate)
    => _db.Posts.Where(predicate);   // IQueryable.Where — server evaluation

Mistake 2 — Calling AsEnumerable() before Skip/Take/Filter operations #

❌ Wrong — loads the full table into memory before pagination.

✅ Correct — keep the query as IQueryable until all server-side operations are applied, then call ToListAsync().