我理解lambdas和Func和Action委托。但表情 我头疼不已。
在什么情况下，你会使用表达式<Func<T>>而不是普通的旧Func<T>?
当前回答
很高兴知道你可以使用Func<TEntity, bool>与AsQueryable()扩展方法，如Expression<Func<TEntity, bool>>。
Func<App, bool> filter = x => x.Alias.Contains("gan");
var query = dbSet.Where(filter).AsQueryable();
在使用Count()或ToList()等执行方法之前，查询不会被执行。
其他回答
当您希望将lambda表达式视为表达式树并查看其内部而不是执行它们时。例如，LINQ to SQL获取表达式并将其转换为等效的SQL语句并将其提交给服务器(而不是执行lambda)。
Conceptually, Expression<Func<T>> is completely different from Func<T>. Func<T> denotes a delegate which is pretty much a pointer to a method and Expression<Func<T>> denotes a tree data structure for a lambda expression. This tree structure describes what a lambda expression does rather than doing the actual thing. It basically holds data about the composition of expressions, variables, method calls, ... (for example it holds information such as this lambda is some constant + some parameter). You can use this description to convert it to an actual method (with Expression.Compile) or do other stuff (like the LINQ to SQL example) with it. The act of treating lambdas as anonymous methods and expression trees is purely a compile time thing.
Func<int> myFunc = () => 10; // similar to: int myAnonMethod() { return 10; }
将有效地编译为一个IL方法，该方法得不到任何结果并返回10。
Expression<Func<int>> myExpression = () => 10;
将被转换为描述不获取参数并返回值10的表达式的数据结构:
大图
虽然它们在编译时看起来是一样的，但编译器生成的内容完全不同。
很高兴知道你可以使用Func<TEntity, bool>与AsQueryable()扩展方法，如Expression<Func<TEntity, bool>>。
Func<App, bool> filter = x => x.Alias.Contains("gan");
var query = dbSet.Where(filter).AsQueryable();
在使用Count()或ToList()等执行方法之前，查询不会被执行。
当您希望将函数视为数据而不是代码时，可以使用表达式。如果您想操作代码(作为数据)，可以这样做。大多数情况下，如果你认为不需要表达式，那么你可能就不需要使用表达式。
我想补充一些关于Func<T>和Expression<Func<T>>的区别:
Func<T> is just a normal old-school MulticastDelegate; Expression<Func<T>> is a representation of lambda expression in form of expression tree; expression tree can be constructed through lambda expression syntax or through the API syntax; expression tree can be compiled to a delegate Func<T>; the inverse conversion is theoretically possible, but it's a kind of decompiling, there is no builtin functionality for that as it's not a straightforward process; expression tree can be observed/translated/modified through the ExpressionVisitor; the extension methods for IEnumerable operate with Func<T>; the extension methods for IQueryable operate with Expression<Func<T>>.
有一篇文章用代码示例描述了细节: LINQ: Func<T> vs. Expression<Func<T>>。
希望对大家有所帮助。
主要原因是当您不想直接运行代码，而是想检查它时。这可能有很多原因:
Mapping the code to a different environment (ie. C# code to SQL in Entity Framework) Replacing parts of the code in runtime (dynamic programming or even plain DRY techniques) Code validation (very useful when emulating scripting or when doing analysis) Serialization - expressions can be serialized rather easily and safely, delegates can't Strongly-typed safety on things that aren't inherently strongly-typed, and exploiting compiler checks even though you're doing dynamic calls in runtime (ASP.NET MVC 5 with Razor is a nice example)
