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