C# expression trees

-time type safety, runtime adaptability, and foreign execution contexts without sacrificing throughput.

Core Solution

Expression trees are immutable ASTs built from System.Linq.Expressions nodes. The implementation strategy revolves around three phases: construction, compilation, and execution/translation.

Step 1: Understand the Node Model

Expression trees consist of strongly-typed nodes. Key types include:

• ParameterExpression: Represents method parameters or lambda inputs
• ConstantExpression: Represents literal values or captured variables
• MemberExpression: Represents property/field access
• BinaryExpression: Represents operations (==, &&, >, etc.)
• MethodCallExpression: Represents method invocations
• LambdaExpression: The root node that binds parameters to a body

Step 2: Construct the Tree

You can build trees manually or capture them from lambda syntax. Manual construction provides full control for dynamic scenarios.

using System.Linq.Expressions;

public static Expression<Func<T, bool>> BuildFilter<T>(string propertyName, object value)
{
    var parameter = Expression.Parameter(typeof(T), "x");
    var property = Expression.Property(parameter, propertyName);
    var constant = Expression.Constant(value, property.Type);
    var equality = Expression.Equal(property, constant);
    
    return Expression.Lambda<Func<T, bool>>(equality, parameter);
}

Step 3: Compile and Cache

Expression trees must be compiled to delegates before execution. Compilation is expensive; cache the result.

public static class ExpressionCompiler
{
    private static readonly ConcurrentDictionary<string, Delegate> _cache = new();

    public static Func<T, bool> CompileAndCache<T>(Expression<Func<T, bool>> expression)
    {
        var key = expression.ToString(); // Simple structural key
        return (Func<T, bool>)_cache.GetOrAdd(key, _ => expression.Compile());
    }
}

Step 4: Execute or Translate

Compiled delegates execute directly. Raw expression trees pass to query providers.

// Direct execution
var filter = BuildFilter<Person>("Age", 30);
var compiled = ExpressionCompiler.CompileAndCache(filter);
var matches = people.Where(compiled).ToList();

// Provider translation (EF Core, IQueryable)
IQueryable<Person> queryable = dbContext.People;
var translated = queryable.Where(filter); // Provider translates to SQL

Architecture Decisions and Rationale

• Use Expression<T> over Delegate for provider boundaries: Query providers require inspectable ASTs. Passing compiled delegates breaks translation pipelines.
• Cache compiled delegates by structural key: Expression trees are immutable. ToString() provides a deterministic structural fingerprint for caching. For high-throughput systems, implement a custom IEqualityComparer<Expression> based on node traversal.
• Prefer ExpressionVisitor for transformation: Direct mutation is impossible. Use visitors to rewrite trees (e.g., parameter rebinding, constant folding, null-safety injection).
• Avoid runtime string parsing for critical paths: String-based property names bypass compile-time validation. Generate expression trees at startup or use source generators for known schemas.

Pitfall Guide

1. Confusing Expression<T> with Func<T> Expression<Func<T, bool>> is a data structure. Func<T, bool> is executable code. Passing an expression to a method expecting a delegate triggers implicit compilation, losing provider compatibility. Always match the expected type to the execution context.

2. Parameter Instance Mismatch Expression trees require exact ParameterExpression reference equality. Creating a new ParameterExpression with the same name breaks binding. Reuse the same instance across all nodes in the tree.

3. Over-Engineering Static Logic Expression trees add construction and compilation overhead. Use them only for dynamic, runtime-determined logic. Static conditions should remain as compiled code.

4. Ignoring ExpressionVisitor for Modifications Trees are immutable. Attempting to modify nodes directly throws exceptions. Use ExpressionVisitor to traverse and rebuild trees with transformations (e.g., injecting != null checks, converting string.Contains to SQL LIKE).

5. Unbounded Cache Growth Caching compiled delegates without a eviction strategy or structural key normalization causes memory leaks in high-cardinality dynamic scenarios. Implement MemoryCache with sliding expiration or limit cache size by expression complexity.

6. Debugging Opacity Expression trees lack source maps. expression.ToString() provides a readable representation but omits line numbers. Use runtime inspection tools or serialize trees to JSON during development to validate node structure.

Best Practices from Production

• Validate property names against TypeDescriptor or compiled metadata before tree construction.
• Use Expression.Parameter(typeof(object), "x") and Expression.Convert for generic dynamic access when type information is unavailable.
• Profile compilation overhead separately from execution. Compilation is a one-time cost; execution should be allocation-free.
• Prefer System.Linq.Expressions over System.Reflection.Emit for maintainability. IL generation offers marginal speed gains but sacrifices readability and provider compatibility.

Production Bundle

Action Checklist

• Define execution context: Determine if the tree will execute locally (compile to delegate) or translate remotely (pass to provider).
• Implement structural caching: Use ConcurrentDictionary with expression.ToString() or a custom node hash for compiled delegates.
• Validate inputs at construction: Check property existence, type compatibility, and null safety before building nodes.
• Use ExpressionVisitor for transformations: Never mutate trees directly; rewrite them for null checks, parameter rebinding, or provider-specific adjustments.
• Profile compilation vs execution: Measure one-time compilation cost separately from delegate invocation to avoid premature optimization.
• Add telemetry for cache hits/misses: Monitor expression reuse patterns to identify caching inefficiencies or memory pressure.
• Document provider boundaries: Clearly separate methods that accept Expression<T> from those that accept Func<T> to prevent accidental compilation.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Dynamic UI filtering with unknown properties	Compiled Expression Tree	Inspectable, type-safe, near-delegate performance	Low (one-time compilation, zero allocation execution)
High-frequency static business rules	Raw Delegate	Lowest latency, no AST overhead	None (compile-time bound)
ORM query translation (EF Core, LINQ-to-SQL)	Expression Tree	Provider requires AST for SQL generation	Medium (provider translation cost)
Cross-language rule engine (JavaScript/Python interop)	Expression Tree + JSON Serialization	AST structure maps to foreign rule formats	High (serialization/deserialization overhead)
Reflection-based property access fallback	Reflection	Only when expression tree construction fails	High (100x+ latency, allocation pressure)

Configuration Template

using System.Collections.Concurrent;
using System.Linq.Expressions;

public static class ExpressionTreeFactory
{
    private static readonly ConcurrentDictionary<string, Delegate> _compiledCache = new();
    private static readonly SemaphoreSlim _compilationLock = new(1, 1);

    public static Func<T, TResult> GetOrCompile<T, TResult>(
        Expression<Func<T, TResult>> expression,
        string? cacheKey = null)
    {
        var key = cacheKey ?? expression.ToString();
        
        if (_compiledCache.TryGetValue(key, out var cached))
            return (Func<T, TResult>)cached;

        _compilationLock.Wait();
        try
        {
            // Double-check after lock
            if (_compiledCache.TryGetValue(key, out cached))
                return (Func<T, TResult>)cached;

            var compiled = expression.Compile();
            _compiledCache[key] = compiled;
            return compiled;
        }
        finally
        {
            _compilationLock.Release();
        }
    }

    public static void ClearCache() => _compiledCache.Clear();
}

Quick Start Guide

1. Define target type and filter condition

   public record Employee(string Department, int YearsOfService);
   

2. Build the expression tree

   var param = Expression.Parameter(typeof(Employee), "e");
   var deptProp = Expression.Property(param, nameof(Employee.Department));
   var constant = Expression.Constant("Engineering");
   var condition = Expression.Equal(deptProp, constant);
   var lambda = Expression.Lambda<Func<Employee, bool>>(condition, param);
   

3. Compile and cache

   var compiledFilter = ExpressionTreeFactory.GetOrCompile(lambda);
   

4. Execute against data

   var staff = new List<Employee>
   {
       new("Engineering", 5),
       new("Sales", 2),
       new("Engineering", 8)
   };
   var results = staff.Where(compiledFilter).ToList();
   

5. Verify translation capability (optional) Pass lambda directly to IQueryable.Where() to confirm provider compatibility without compilation.

Expression trees are not a niche optimization. They are the structural bridge between compile-time safety and runtime adaptability in .NET. Master their construction, cache their compilation, and respect provider boundaries, and you eliminate the performance debt that plagues dynamic filtering, rule evaluation, and cross-boundary query translation.