我理解在 ASP.NET MVC 中使用 HTML 帮助程序并将其扩展为提供您自己的帮助程序的原因，但我想知道使用 HTML 帮助程序是否是一个好主意。
我认为 ASP.NET MVC 的好处之一是对 HTML 的控制。如果您开始将其隐藏在生成 HTML 的辅助函数中，您是否会开始失去可见性？我想当您生成简单的控件（例如按钮）时，这不是问题，但是我已经看到使用 html 助手来创建网格和更复杂的 HTML 输出。
现在我也明白这样做的原因是为了保持干燥，避免重复。但是这里有类似于代码隐藏的东西的危险吗？此外，如果您与设计师合作怎么办？通常，设计师会创建标记并应用样式。如果您开始使用生成标记的助手注入您的视图，这不会使这种协作变得困难吗？
“对 HTML 的控制”是微软的营销语言，也是他们选择平台品牌的方式。ASP.net MVC 的重点在于它比整个有状态事件驱动的 web 表单模型更简单，更适合 webapps，而且微软领域之外的几乎所有人都在几年前转向了这种模型。不过，微软不能这么说，因为他们在网络表单上进行了巨额投资，这是他们企业故事的关键部分。
话虽如此，如果您的助手中有业务逻辑，那么您使用它们是错误的。它基本上是仅在多个页面中重复的表示逻辑的代码隐藏，目标是使标记中的 scriptlet 标记尽可能简单。
只要您以应有的方式使用助手，设计人员学习如何使用应该是相当简单的。请记住，我们的目标是让事情变得简单，如果它们最终使事情变得更复杂，则意味着它们没有被正确使用。
很好的评论，马特。仍然存在一个问题，即在“纯”MVC 实现中，HTML 助手是否是一个好主意。我认为这是一个神奇的词，“纯”。每当我放慢脚步思考“正确”的做事方式时，我真的在尝试看看某个特定的方法是否符合纯粹主义者的愿景。那么，纯粹主义者会使用 HTML 助手吗？
我大约是 8/10 的纯粹主义者，我不会使用它们。我已经看到这个论点超越了技术，并提出了 PHP 和 Zend 框架中的 MVC 问题。只是感觉不对，对我来说，这是人们能想到的最好的衡量标准。
帮手肯定没有错。它们用于使您的视图保持简洁和声明性。有一种说法类似于“如果您认为有“如果”陈述，那么您做错了”。它们被用于许多著名的 MVC 框架，如 Ruby On Rails 和 Cake PHP。看看这篇文章。“纯粹”与否，助手是一件好事，不要与糟糕的实践或泄漏的抽象相混淆。
我认为其他人没有提到的重要一点是您的观点的可移植性。
您可以立即将您的 HTML、javascript 和 CSS 移动到另一个平台上的应用程序中。您不必将所有丑陋的 HTMLHiders.. 抱歉，HTMLHelpers.. 转换为实际的 HTML。
虽然我非常重视 .NET 框架，它减少了我的开发时间并使我的工作变得轻松，但我强烈认为视图应该是非专有的。
无论如何，您都可以从模型和控制器中的框架中获得几乎所有的好处。IMO，在表示层中注入对框架的依赖项根本不值得权衡。