为什么在 ASP.NET MVC 中使用 lambdas 而不是反射？答案

【问题标题】：Why use lambdas in ASP.NET MVC instead of reflection?为什么在 ASP.NET MVC 中使用 lambdas 而不是反射？
【发布时间】：2013-01-23 23:55:29
【问题描述】：

使用 Asp.Net MVC 已经有一段时间了，但我遇到了一个非常奇怪的问题。每次创建模型时，我都会使用 lambda 表达式，例如：

@Html.EditorFor(model=>model.SomeProperty)

为什么 Asp.Net MVC 使用这种类型的架构？

为什么我不能只使用反射传入一个属性？

使用 lambda 表达式是否更快？因为在幕后我认为要获得属性名称，它必须使用反射。

【问题讨论】：

您是否希望在 Razor 视图中为每个标签/编辑/显示设置类似 @Html.EditorFor(typeof(ParvsModel).GetProperty("SomeProperty"), BindingFlags.Public) 的内容？
您可以使用@Html.Editor("SomeProperty")，但是对于喜欢强类型的人来说，存在 lambda 版本。我最近也在一篇博文中介绍了这个主题：odetocode.com/blogs/scott/archive/2012/11/26/…

【解决方案1】：

Lambda > 反射

使用 lambdas 你得到：

多亏了 lambdas，任何 API 都可以从属性选择器中知道很多东西：

public static MvcHtmlString EditorFor<TModel, TValue>(
    this HtmlHelper<TModel> html,
    Expression<Func<TModel, TValue>> expression
)

它是一个表达式树，而不是一个常规的 lambda。这允许 MVC（以及任何 API）操作表达式，以便在运行时调用它之前添加更多行为，而无需反射发射。

了解有关表达式树的更多信息：

【讨论】：

【解决方案2】：

我的回答不会受欢迎。

出于三个原因，我相信 99% 的 Lambda 始终是更好的选择。

首先，假设您的开发人员很聪明，这绝对没有错。其他答案有一个基本前提，即除了您之外的每个开发人员都是愚蠢的。不是这样。

其次，Lamdas (et al) 是一种现代语法 - 明天它们将比现在更普遍。您的项目代码应遵循当前和新兴的约定。

第三，以“老式方式”编写代码对您来说似乎更容易，但对编译器来说却并不容易。这很重要，随着编译器的修订，遗留方法几乎没有机会改进。依赖编译器来扩展它们的 Lambdas（等）可以受益，因为编译器会随着时间的推移更好地处理它们。

总结一下：

再一次，我知道这不会是一个受欢迎的答案。相信我，“简单就是最好”也是我的口头禅。维护是任何来源的重要方面。我知道了。但我认为我们用一些陈词滥调的经验法则掩盖了现实。

【讨论】：