我理解lambdas和Func和Action委托。但表情 我头疼不已。

在什么情况下,你会使用表达式<Func<T>>而不是普通的旧Func<T>?


当前回答

在选择表达式和Func时,一个非常重要的考虑因素是IQueryable提供者,如LINQ to Entities可以“消化”你在表达式中传递的内容,但会忽略你在Func中传递的内容。关于这个主题,我有两篇博文:

更多关于表达式vs函数与实体框架和 爱上LINQ -第7部分:表达式和功能函数(最后一部分)

其他回答

在Krzysztof Cwalina的书(框架设计指南:可重用的。net库的约定、习惯用法和模式)中有一个更哲学的解释;

编辑非图像版本:

大多数情况下,如果你只需要运行一些代码,你就需要Func或Action。当代码在运行之前需要分析、序列化或优化时,就需要使用Expression。表达式是用来思考代码的,Func/Action是用来运行代码的。

在选择表达式和Func时,一个非常重要的考虑因素是IQueryable提供者,如LINQ to Entities可以“消化”你在表达式中传递的内容,但会忽略你在Func中传递的内容。关于这个主题,我有两篇博文:

更多关于表达式vs函数与实体框架和 爱上LINQ -第7部分:表达式和功能函数(最后一部分)

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

我添加了一个针对新手的答案,因为这些答案似乎超出了我的理解范围,直到我意识到它是多么简单。有时是你认为事情很复杂,这让你无法“理清思路”。

我不需要理解其中的区别,直到我遇到了一个非常烦人的“bug”,试图一般地使用LINQ-to-SQL:

public IEnumerable<T> Get(Func<T, bool> conditionLambda){
  using(var db = new DbContext()){
    return db.Set<T>.Where(conditionLambda);
  }
}

这工作得很好,直到我开始在更大的数据集上得到outofmemoryexception。在lambda中设置断点使我意识到它正在逐一遍历表中的每一行,寻找与lambda条件匹配的条件。这让我困惑了一段时间,因为为什么它把我的数据表作为一个巨大的IEnumerable,而不是像它应该做的那样做LINQ-to-SQL ?它也在我的LINQ-to-MongoDb对应版本中做同样的事情。

修复方法是简单地将Func<T, bool>转换为表达式<Func<T, bool>>,所以我谷歌了为什么它需要一个表达式而不是Func,在这里结束。

表达式只是将委托转换为关于自身的数据。所以a => a + 1就变成了"左边有一个整数a,右边你给它加1 "就是这样。你现在可以回家了。它显然比这更有结构,但这本质上就是表达式树的全部——没有什么可以让你理解的。

Understanding that, it becomes clear why LINQ-to-SQL needs an Expression, and a Func isn't adequate. Func doesn't carry with it a way to get into itself, to see the nitty-gritty of how to translate it into a SQL/MongoDb/other query. You can't see whether it's doing addition or multiplication or subtraction. All you can do is run it. Expression, on the other hand, allows you to look inside the delegate and see everything it wants to do. This empowers you to translate the delegate into whatever you want, like a SQL query. Func didn't work because my DbContext was blind to the contents of the lambda expression. Because of this, it couldn't turn the lambda expression into SQL; however, it did the next best thing and iterated that conditional through each row in my table.

编辑:应约翰·彼得的要求,对我的最后一句话进行解释:

IQueryable extends IEnumerable, so IEnumerable's methods like Where() obtain overloads that accept Expression. When you pass an Expression to that, you keep an IQueryable as a result, but when you pass a Func, you're falling back on the base IEnumerable and you'll get an IEnumerable as a result. In other words, without noticing you've turned your dataset into a list to be iterated as opposed to something to query. It's hard to notice a difference until you really look under the hood at the signatures.

当使用LINQ-to-SQL时,将Func<>s传递给Where()或Count()是不好的。真正的坏。如果你使用Func<>,那么它调用IEnumerable LINQ的东西,而不是IQueryable,这意味着整个表被拉进来,然后过滤。表达式<Func<>>明显更快,因为它在SQL服务器上执行过滤-特别是如果您正在查询位于另一个服务器上的数据库。