为啥在 ASP.NET MVC 中使用 lambdas 而不是反射?
Posted
技术标签:
【中文标题】为啥在 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 你得到:
设计时的强类型属性选择器。 使用内置的 Visual Studio 重构工具轻松进行重构。多亏了 lambdas,任何 API 都可以从属性选择器中知道很多东西:
属性类型。 属性的对象。 检查属性元数据。另外,检查方法签名(http://msdn.microsoft.com/en-us/library/ee402949(v=vs.108).aspx):
public static MvcHtmlString EditorFor<TModel, TValue>(
this HtmlHelper<TModel> html,
Expression<Func<TModel, TValue>> expression
)
它是一个表达式树,而不是一个常规的 lambda。这允许 MVC(以及任何 API)操作表达式,以便在运行时调用它之前添加更多行为,而无需反射发射。
了解有关表达式树的更多信息:
http://msdn.microsoft.com/en-us/library/bb397951.aspx【讨论】:
【参考方案2】:我的回答不会受欢迎。
出于三个原因,我相信 99% 的 Lambda 始终是更好的选择。
首先,假设您的开发人员很聪明,这绝对没有错。其他答案有一个基本前提,即除了您之外的每个开发人员都是愚蠢的。不是这样。
其次,Lamdas (et al) 是一种现代语法 - 明天它们将比现在更普遍。您的项目代码应遵循当前和新兴的约定。
第三,以“老式方式”编写代码对您来说似乎更容易,但对编译器来说却并不容易。这很重要,随着编译器的修订,遗留方法几乎没有机会改进。依赖编译器来扩展它们的 Lambdas(等)可以受益,因为编译器会随着时间的推移更好地处理它们。
总结一下:
-
开发人员可以处理它
每个人都在这样做
有未来的潜力
再一次,我知道这不会是一个受欢迎的答案。相信我,“简单就是最好”也是我的口头禅。维护是任何来源的重要方面。我知道了。但我认为我们用一些陈词滥调的经验法则掩盖了现实。
【讨论】:
以上是关于为啥在 ASP.NET MVC 中使用 lambdas 而不是反射?的主要内容,如果未能解决你的问题,请参考以下文章
为啥总是在 asp.net mvc 中同步异步操作(async await)
为啥 Asp.net MVC 不能区分具有不同参数的两个动作?
在默认的 ASP.Net MVC 模板中,为啥用户每次更改时都会重新登录?