ASP MVC HTML Helpers - 好还是坏？

Question

我了解在ASP.NET MVC中使用HTML辅助程序并扩展它的原因，但我想知道是否使用HTML辅助程序是一个好主意。

我认为ASP.NET MVC的一个好处是可以控制HTML。如果您开始将它隐藏在生成HTML的帮助器函数中，那么您不就开始失去可见性了吗？当您生成简单的控件（例如按钮）时，这可能并不是问题，但我曾看到使用html helpers创建网格和更复杂的HTML输出。

我也理解这样做的原因是为了保持DRY，避免重复。但这里是否有类似于代码后台的危险呢？此外，如果您正在与设计师进行协作，该怎么办？通常情况下，设计师会创建标记并应用样式。如果您开始向视图注入生成标记的帮助器，那么这是否会使这种协作变得困难？

- Jon Archway

---

不。只要助手没有违反MVC的关注点，也就是说他们没有做任何与表示逻辑无关的事情，那么他们就没有问题。是的，一些复杂的助手可能实际上会违反关注点分离，但这确实是一个与助手本身是好还是坏的论点不同的争论。 - Erik Funkenbusch

Answer 1

“Control over the HTML”是微软的营销用语，这是他们选择品牌平台的方式。ASP.net MVC 的重点在于它比WebForms完整的状态事件驱动模型更简单，更适合Web应用程序，而且几乎所有不属于微软领域的人都已经转向多年了。然而微软无法这样说，因为他们对WebForms有着巨大的投资，并且它是他们企业故事的关键部分。

话虽如此，如果您的辅助功能中有业务逻辑，则使用不正确。这基本上是表示逻辑的代码后端，重复出现在多个页面上，目标是保持标记中的脚本标签尽可能简单。

只要您按照正确方式使用助手，设计师应该很容易学会如何使用。只需记住，目标是保持简单，如果最终使事情变得更加复杂，这意味着它们没有被正确使用。

- Matt Briggs

Answer 2

很好的评论，马特。在“纯粹”的MVC实现中，HTML助手是否是一个好主意还存在疑问。我认为这就是魔术词语，“纯粹”。每当我放慢脚步考虑“正确”做事方式时，我真正想知道的是某个方法是否符合纯粹主义者的愿景。那么，纯粹主义者会使用HTML助手吗？

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

- Ivan Mercedes

---

在MVC模式中，并没有规定不能使用辅助函数来生成模板标记代码。MVC只关注于关注点的分离。只要你的辅助函数不违反关注点的边界，那么MVC对此无可指摘。因此，在严格的模式角度上，“纯粹”的MVC并不涉及其中任何方面，因为它没有处理MVC的任何方面。这些辅助函数完全是视图（MVC中的V）的一个特性。 - Erik Funkenbusch

Answer 3

使用助手函数来保持视图的干净和声明性是没有问题的。有一句话说得很好：“如果在你的视图中出现了‘if’语句，那么你就做错了”。这些函数在许多著名的MVC框架中被使用，比如Ruby On Rails和Cake PHP。可以查看这篇文章。无论你是“纯粹主义者”还是不是，助手函数都是好的，不应与坏实践或泄漏抽象混淆。

- A-Dubb

Answer 4

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

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

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

在模型和控制器中几乎可以获得框架的所有好处。在演示层注入对框架的依赖根本不值得这种权衡，以我个人的看法。

- Zesty