当您希望将函数视为数据而不是代码时，可以使用表达式。如果您想操作代码(作为数据)，可以这样做。大多数情况下，如果你认为不需要表达式，那么你可能就不需要使用表达式。

很高兴知道你可以使用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()等执行方法之前，查询不会被执行。

LINQ是典型的例子(例如，与数据库对话)，但事实上，任何时候您更关心表达要做什么，而不是实际做什么。例如，我在protobuf-net的RPC堆栈中使用这种方法(以避免代码生成等)-所以你调用一个方法:

string result = client.Invoke(svc => svc.SomeMethod(arg1, arg2, ...));

这将分解表达式树以解析SomeMethod(以及每个参数的值)，执行RPC调用，更新任何ref/out参数，并从远程调用返回结果。这只能通过表达式树实现。我在这里讲得更多。

另一个例子是为了编译为lambda而手动构建表达式树，就像使用泛型操作符代码一样。

这里过于简化了，但Func是一个机器，而Expression是一个蓝图。: D

这是我的两分钱…

Func<T> =一个刚被执行的委托/方法，仅此而已。 表达式<Func<T>> =转换为另一种形式。例如，LINQ to Entities表达式被转换为等效的SQL查询。

想象一下，两者看起来很相似，但表达式就像一个数据结构，具有反射的能力。编译器实际上知道关于它的签名和主体的所有信息(类似于类反射)。利用这些知识，表达式被转换为其他形式，就像LINQ被转换为SQL查询一样。

现在，还有另一个角度来处理IQueryable行为。建议您始终传递LINQ的Expression to Where或Count方法，以便您的查询过滤器在SQL server上运行，而不是在内存中提取数据然后进行过滤。

当您希望将函数视为数据而不是代码时，可以使用表达式。如果您想操作代码(作为数据)，可以这样做。大多数情况下，如果你认为不需要表达式，那么你可能就不需要使用表达式。