ASP MVC HTML Helpers - 好还是坏？答案

【问题标题】：ASP MVC HTML Helpers - Good or Bad?ASP MVC HTML Helpers - 好还是坏？
【发布时间】：2009-04-08 15:56:16
【问题描述】：

我理解在 ASP.NET MVC 中使用 HTML 帮助程序并将其扩展为提供您自己的帮助程序的原因，但我想知道使用 HTML 帮助程序是否是一个好主意。

我认为 ASP.NET MVC 的好处之一是对 HTML 的控制。如果您开始将其隐藏在生成 HTML 的辅助函数中，您是否会开始失去可见性？我想当您生成简单的控件（如按钮）时这不是问题，但我已经看到使用 html 助手来创建网格和更复杂的 HTML 输出。

现在我也明白这样做的原因是为了保持干燥，避免重复。但是这里有类似于代码隐藏的东西的危险吗？此外，如果您与设计师合作怎么办？通常，设计师会创建标记并应用样式。如果您开始使用生成标记的助手注入您的视图，这不会使这种协作变得困难吗？

【问题讨论】：

没有。只要助手没有违反 MVC 的关注点，即他们正在做一些不是表示逻辑的事情，那么他们就没有错。是的，一些复杂的助手实际上可能违反了关注点分离，但这与助手本身是好是坏是完全不同的。

标签： .net asp.net-mvc html-helper

【解决方案1】：

“对 HTML 的控制”是微软营销的说法，也是他们选择平台品牌的方式。 ASP.net MVC 的重点在于它比整个有状态事件驱动的 web 表单模型更简单，更适合 webapps，而且微软领域之外的几乎所有人都在几年前转向了这种模型。不过微软不能这么说，因为他们在网络表单上投入了大量资金，这是他们企业故事的关键部分。

话虽如此，如果您的助手中有业务逻辑，则说明您使用错误。它基本上是只在多个页面中重复的表示逻辑的代码隐藏，目标是使标记中的 scriptlet 标记尽可能简单。

只要您以应有的方式使用帮助程序，设计人员学习如何使用应该是相当简单的。请记住，我们的目标是让事情变得简单，如果它们最终使事情变得更复杂，则意味着它们没有被正确使用。

【讨论】：

【解决方案2】：

很好的评论，马特。仍然存在一个问题，即在“纯”MVC 实现中，HTML 助手是否是一个好主意。我认为这是一个神奇的词，“纯”。每当我放慢脚步思考“正确”的做事方式时，我真的在尝试看看某个特定的方法是否符合纯粹主义者的愿景。那么，纯粹主义者会使用 HTML 助手吗？

我大约是 8/10 的纯粹主义者，我不会使用它们。我已经看到这个论点超越了技术，并提出了 PHP 和 Zend 框架中的 MVC 问题。只是感觉不对，对我来说，这是人们能想到的最好的衡量标准。

【讨论】：

MVC 模式中没有任何内容表明您不能使用辅助函数来生成模板标记代码。 MVC 只讨论关注点分离。只要您的辅助函数没有违反关注点的边界，那么 MVC 就无话可说。因此，从严格模式的角度来看，这种“纯”MVC 并没有涉及到它，因为没有任何东西可以处理 MVC 的任何方面。这些助手纯粹是视图的一个特性（MVC 中的 V）。

【解决方案3】：

帮助者绝对没有错。它们用于使您的视图保持简洁和声明性。有一种说法类似于“如果您认为有一个“如果”陈述，那么您做错了”。它们被用于许多著名的 MVC 框架，如 Ruby On Rails 和 Cake PHP。查看this post。不管“纯粹”与否，助手都是一件好事，不要与糟糕的实践或泄漏的抽象混淆。

【讨论】：

【解决方案4】：

我认为其他人没有提到的重要一点是您的观点的可移植性。

您可以立即将您的 HTML、javascript 和 CSS 移动到另一个平台上的应用程序中。您不必将所有丑陋的 HTMLHiders.. 抱歉，HTMLHelpers.. 转换为实际的 HTML。

虽然我非常重视 .NET 框架，它减少了我的开发时间并让我的工作变得轻松，但我强烈认为视图应该是非专有的。

无论如何，您都可以从模型和控制器中的框架中获得几乎所有的好处。在表示层中注入对框架的依赖项根本不值得权衡，IMO。

【讨论】：