DelegateDecompiler

To add a new test to the harness, follow this standard workflow within a test file:

1. Setup: Ensure the file has a TestFixture at the top to initialize logging.
2. Environment: Set up the test environment to obtain a reference to the EF DbContext.
3. Test Native LINQ: Execute the LINQ command directly against the EF context.
4. Switch to DelegateDecompiler: Call env.AboutToUseDelegateDecompiler(); to signal the transition to testing [Computed] properties.
5. Test Computed Property: Execute the same command using the [Computed] property (which must be added to an EF class like EfPerson or EfParent).
6. Compare Results: Use the appropriate comparison method based on the return type:
   • For single values: CompareAndLogSingleton
   • For collections: Use .ToList() on the query, then CompareAndLogList.

Important: If testing a filter command like .Where(), you MUST add a .Select() statement to pick a known, simple property (e.g., ParentId). This prevents other [Computed] properties from interfering with the native LINQ part of the test.

// Example pattern for a test method
[Test]
public void TestEquals() 
{
    // 1. Setup environment/DbContext
    // 2. Test LINQ version
    var result1 = context.People.Where(p => p.Name == "John").Select(p => p.Id).ToList();

    // 3. Signal DelegateDecompiler usage
    env.AboutToUseDelegateDecompiler();

    // 4. Test [Computed] version
    var result2 = context.People.Where(p => p.ComputedName == "John").Select(p => p.Id).ToList();

    // 5. Compare
    CompareAndLogList(result1, result2);
}

DelegateDecompiler allows you to use C# computed properties within LINQ queries by decompiling them into their underlying expression tree representation. This enables ORMs to translate these properties into SQL.

Using the [Computed] attribute

Decorate your property with the [Computed] attribute to enable automatic decompilation when calling .Decompile().

Using the .Computed() extension method

If you cannot modify the class to add the [Computed] attribute, use the .Computed() extension method on the property within your query.

Example usage

// With [Computed] attribute
var employees = (from employee in db.Employees
                 where employee.FullName == "Test User"
                 select employee).Decompile().ToList();

// Without [Computed] attribute
var employees = (from employee in db.Employees
                 where employee.FullName.Computed() == "Test User"
                 select employee).ToList();

// Using with methods like Any()
bool exists = db.Employees.Decompile().Any(employee => employee.FullName == "Test User");

class Employee
{
    [Computed]
    public string FullName => FirstName + " " + LastName;
    public string LastName { get; set; }
    public string FirstName { get; set; }
}

// Querying
var employees = (from employee in db.Employees
                 where employee.FullName == "Test User"
                 select employee).Decompile().ToList();

When using ORMs like Entity Framework, follow these rules to ensure successful decompilation:

Call order

Always call .Decompile() or .DecompileAsync() after all ORM-specific methods (such as .Include(), .AsNoTracking(), or .Fetch()) and just before materialization methods (such as .ToList(), .ToArray(), .First(), .Count(), or .Any()).

Async support

• For EF6: Use the DecompileAsync extension method provided by the DelegateDecompiler.EntityFramework package.
• For EF Core 5.0+: Use the DecompileAsync extension method provided by the DelegateDecompiler.EntityFrameworkCore5 package.

Automatic decompilation (EF Core only)

In EF Core, you can configure the DbContext to automatically decompile all queries so you don't have to call .Decompile() manually.

public class YourDbContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder options) {
        options.AddDelegateDecompiler();
        // Other configuration
    }
}

When using DelegateDecompiler with Entity Framework v6.1, the following LINQ command patterns are supported for use within Computed properties. This list is derived from direct comparisons between standard EF LINQ queries and DelegateDecompiler-enabled queries.

Basic Features

• Select: Includes selecting properties/methods without attributes, abstract members over TPH (Table Per Hierarchy) hierarchies, and SelectMany.
• Select Async: Supports async and non-generic async operations, including boolean comparisons with constants or static variables.
• Equals and Not Equals: Supports integer comparisons against constants, static variables, and string lengths.
• Nullable: Supports property null checks, nullable initialization, and nullable arithmetic.
• Where: Supports filtering on constants, static variables, and abstract members over TPH hierarchies.
• Single / Single Async: Supports retrieving a single item where an integer equals a unique value.

Order and Pagination

• Order By: Supports ordering by children count, ordering by children count then string length, and combining Any with OrderBy.
• Skip Take: Supports pagination (Skip/Take) combined with ordering and Any filters.

Quantifier Operators

• Any: Supports checking for any children or any children with a specific filter.
• All: Supports singleton All filters and filters on children integers.
• Contains: Supports string constant containment with filters.

Aggregation

• Count / Count Async: Supports counting children, counting with filters, and counting with closures (internal or external).
• Sum: Supports summing children and summing counts in children where children might be null.

Types and Additional Features

• Strings: Supports concatenation (handling nulls and name order) and generic methods for selection/filtering.
• DateTime: Supports comparing DateTime against static variables.
• Nested Expressions: Supports subqueries used as context extension methods.