C#MVC:MVC Html助手与视图中的直接HTML的性能和优势

我想知道Html助手对C#ASP.NET MVC视图有什么样的性能影响,特别是在设置属性参数时,以及它们总体上有哪些优点(为什么要使用它们？)

使用Html助手:

<%= Html.TextBox("firstName", Model.FirstName, 
    new { @disabled = "disabled", @class = "myCssClass" }) %>

直接Html:

我有很多页面包含5到15个这样的输入.最重要的是,Html Helpers允许你渲染表单(想想Html.BeginForm())等,这样你最终可能会得到20个甚至更多的Html Helper调用.我认为其中一些也使用反射,例如当您设置上面的禁用属性时.

这样做不会对性能产生巨大影响吗？为什么使用这些助手被认为是更好的做法？请有人给我一个很好的理由:)我想使用它们但我真的担心它们对性能的影响.

使用Html助手有什么真正的好处吗？

1> James H..：

---

做反思的开销是人们真正想要担心的事情.然而,在综合基准测试之外,它变得非常无聊!

在实际生产应用程序的上下文中(例如,您正在对数据库执行CRUD操作或使用Web服务),与执行此类上下文切换的开销相比,使用html帮助程序的开销将是微不足道的.

真的不用担心,尤其是考虑到html帮助程序提供的好处,例如从ViewData/Model自动恢复表单值以及验证支持.

底线:尽可能使用html助手.如果您遇到需要解决的罕见限制,您可以随时使用直接HTML.

---

总之 - 不要预先优化!

---

这不回答海报问题.性能/开销不是一个"无聊的主题",不仅要了解流程如何工作,还要了解如何创建优化和高效的代码.此外,海报没有询问与CRUD操作有关的表现,所以给出的解释是静音和毫无意义的."真的没有什么值得担心的,特别是考虑到这些好处......" - 是的,无论好处如何,都要担心.总是对性能进行编码,性能更好意味着服务器资源中的$$$更少,更快乐的最终用户!

2> Brett Postin..：

---

使用Html助手有什么真正的好处吗？

我在使用HtmlHelpers时看到的最大优势是为您的标记提供了一个抽象层.如果将来您想要更改标记的结构,则只需更改帮助程序生成的输出,而不是浏览所有视图并进行手动更改.

它还促进了开发团队之间的一致性.这些开发人员不需要知道标记结构和UI所基于的CSS类的确切细节.

作为一个例子,我正在为我为基于Bootstrap工作的公司开发一个新的UI框架.我创建了一组HtmlHelper,为各种Bootstrap组件生成适当的标记和css类.这一切都是在Fluent API中完成的,这对开发人员来说很好用,没有Bootstrap所需的任何深入知识,还有可以使用Intellisense的额外好处.

Telerik的Kendo UI框架基于相同的概念.看看他们的一些代码示例.

至于反射和性能,考虑到可能涉及一些HtmlHelper方法的调用次数,我真的不会担心.请参阅此帖子了解原因.