Question

This is a follow up to a question I asked earlier seen here:

Confused about passing Expression vs. Func arguments

The accepted answerer there suggests refactoring an Expression referencing local objects into something that Linq to Entities can actually execute against the backing store (in my case SQL Server)

I’ve spent a long time trying to come up with something that will work for what I’m doing. My original

Func<Thing, bool> whereClause

was referencing a local Dictionary object which Linq to Entities or SQL could not understand at runtime. I tried refactoring into multiple lists which faked a dictionary, and Arrays after that. Each time, I got runtime errors complaining about the context doesn’t recognize things like the methods on a List, or array indexers.

Eventually I gave up and just provided an additional method which takes a Func argument for when I cannot come up with the proper Expression.

I’m not trying to find a solution to my specific problem, I’m just wondering in general if it is always possible to convert, say a

Func<Thing, bool>

to an equivalent

Expression<Func<Thing, bool>>

which can run against Linq to Entities.
Or if there are many examples of querys where you simply must pull the data into memory first.

Answer 1

You don’t convert a Func to an expression tree – the compiler converts a lambda expression to an expression tree… and no, that’s not always possible. For example, you can’t convert a statement lambda to an expression tree:

Expression<Func<string, int>> valid = text => text.Length;

Expression<Func<string, int>> invalid = text => { return text.Length; };

There are various other restrictions, too.

Even when you can create an expression tree (and if you do it manually you can build ones which the C# compiler wouldn’t, particularly in .NET 4) that’s not the same thing as the expression tree representing something that LINQ to SQL (etc) can translate appropriately.