为什么要使用Expression <Func <T >>而不是Func <T>？

我正在添加一个回答因为这些答案似乎超出了我的想法,直到我意识到它是多么简单.有时候你的期望是复杂的,让你无法"绕过它".

直到我走进一个非常烦人的'bug'试图一般地使用LINQ-to-SQL之前,我不需要理解它的区别:

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

这很有效,直到我开始在更大的数据集上获取OutofMemoryExceptions.在lambda中设置断点让我意识到它在我的表中逐行迭代寻找与我的lambda条件的匹配.这让我感到困惑了一段时间,因为为什么它将我的数据表视为一个巨大的IEnumerable而不是像它应该做的LINQ-to-SQL？它在我的LINQ-to-MongoDb版本中也做了完全相同的事情.

修复只是变成Func了Expression>,所以我用谷歌搜索为什么它需要一个Expression而不是在Func这里结束.

表达式只是将委托转换为关于自身的数据.所以a => a + 1变成了"在左侧有一个int a.在右侧你加1." 而已.你现在可以回家了.它显然比那更有条理,但基本上所有的表达树真的是 - 没有什么可以包裹你的头.

理解这一点,很清楚为什么LINQ-to-SQL需要一个Expression,而且Func还不够.Func不带有它进入自身的方式,看看如何将其转换为SQL/MongoDb /其他查询的细节.你无法看到它是否在减法中进行加法或乘法.你所能做的只是运行它.Expression另一方面,允许您查看委托内部并查看它想要执行的所有操作,使您能够将其转换为您想要的任何内容,例如SQL查询.Func没有用,因为我的DbContext对lambda表达式中的实际内容是盲目的把它变成SQL,所以它做了下一个最好的事情,并通过我表中的每一行迭代条件.

编辑:在John Peter的要求下阐述我的最后一句话:

IQueryable扩展了IEnumerable,因此IEnumerable的方法就像Where()获取接受的重载一样Expression.当你传递Expression给它时,你会保留一个IQueryable,但是当你传递一个时Func,你会回到基础IEnumerable上,结果你会得到一个IEnumerable.换句话说,没有注意到您已将数据集转换为要迭代的列表而不是要查询的内容.在您真正了解签名之前,很难注意到差异.

在选择Expression vs Func时,一个非常重要的考虑因素是像LINQ to Entities这样的IQueryable提供者可以"消化"你在Expression中传递的内容,但会忽略你在Func中传递的内容.我有两个关于这个主题的博客文章:

更多关于Expression vs Func with Entity Framework并 爱上LINQ的内容 - 第7部分:表达式和函数(最后一节)

我想补充约之间的差异的一些注意事项Func和Expression>:

Func 只是一个普通的老式MulticastDelegate;

Expression> 是表达式树形式的lambda表达式的表示;

表达式树可以通过lambda表达式语法或API语法构建;

表达式树可以编译为委托Func;

逆转换在理论上是可行的,但它是一种反编译,没有内置功能,因为它不是一个简单的过程;

表达树可以通过ExpressionVisitor; 观察/翻译/修改;

IEnumerable的扩展方法与Func;

IQueryable的扩展方法与Expression>.

有一篇文章用代码示例描述了细节:
LINQ:Func vs. Expression >.

希望它会有所帮助.

Krzysztof Cwalina的书(框架设计指南:可重用.NET库的约定,惯用法和模式)对此有更多的哲学解释;

编辑非图像版本:

大多数情况下,如果需要执行的只是运行一些代码,您将需要Func或Action.在代码需要在运行之前进行分析,序列化或优化时,您需要Expression.表达式用于思考代码,Func/Action用于运行代码.

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

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

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

另一个例子是当你手动构建表达式树以便编译为lambda时,就像通用运算符代码所做的那样.

如果要将函数视为数据而不是代码,则可以使用表达式.如果要操作代码(作为数据),可以执行此操作.大多数情况下,如果您不需要表达式,那么您可能不需要使用表达式.

主要原因是您不想直接运行代码,而是想要检查它.这可能有多种原因:

将代码映射到不同的环境(即,实体框架中的C#代码到SQL)

在运行时替换部分代码(动态编程甚至简单的DRY技术)

代码验证(在模拟脚本或进行分析时非常有用)

序列化 - 表达式可以相当容易和安全地序列化,代理人不能

即使你在运行时进行动态调用,也不会强烈地键入强大类型的东西,并利用编译​​器检查(带有Razor的ASP.NET MVC 5就是一个很好的例子)

我还没有看到任何提及性能的答案.传递Func<>进入Where()或者进入Count()是坏的.真的很糟糕 如果你使用a Func<>然后它调用IEnumerableLINQ东西而不是IQueryable,这意味着整个表被拉入然后被过滤. Expression>显着更快,特别是如果您查询的是另一台服务器的数据库.