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

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


当前回答

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

编辑非图像版本:

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

其他回答

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

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

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

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

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

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

编辑非图像版本:

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

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

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