我明白在ASP.NET MVC中使用HTML助手并将其扩展为提供自己的原因，但我想知道使用HTML助手是否是一个好主意。ASP MVC HTML助手 - 好还是坏？
我认为ASP.NET MVC的好处之一就是控制HTML。如果你开始将它隐藏在生成HTML的助手函数中，你不会开始失去可见性吗？我想这是不是这样的问题，当你生成简单的控件，如按钮，但我已经看到使用HTML助手来创建网格和更复杂的HTML输出。
现在我也明白这样做的理由是保持干爽，避免重复。但是在这里没有类似于代码的危险吗？另外，如果您正在与设计师合作，该怎么办？通常，设计师将创建标记并应用样式。如果你开始用产生标记的助手注入视图，这难道不会使这种协作变得困难吗？
“控制HTML”是微软营销发言，他们是如何选择品牌的平台。 ASP.net MVC的重点在于它更简单，更适合于webapps，然后是整个有状态事件驱动的webforms模型，以及微软空间之外几乎所有人都转移到数年前的东西。尽管微软不能这么说，因为他们对webforms有巨大的投资，而且这是他们企业故事的关键部分。
这就是说，如果你有助手的业务逻辑，你使用它们是错误的。它基本上只是在多个页面中重复使用的表示逻辑的代码，目标是尽可能简化标记中的scriptlet标记。
只要你按照他们应该使用的方式使用助手，设计师应该学会如何使用它们应该是相当微不足道的。请记住，目标是保持简单，如果它们最终使事情变得更加复杂，就意味着它们没有被正确使用。
很好的评论，马特。仍然存在一个问题：在“纯粹的”MVC实现中，HTML助手是否是一个好主意。我认为这就是“纯”的魔术词。每当我放慢思考“正确”做事的方式时，我真的在试着看看一种特定的方法是否符合纯粹主义的愿景。那么，纯粹主义者会使用HTML助手吗？
我约8/10纯粹主义，我不会使用它们。我见过这个观点超越了技术，并且在PHP和Zend框架中引发了MVC的问题。它只是感觉不对，对我来说，这是人们可以想到的最好的措施。
MVC模式中没有什么说你不能使用帮助函数来生成模板标记代码。 MVC只谈论关注的分离。只要你的帮助函数没有违反关注的边界，那么MVC就没有什么可说的了。从严格模式的角度来看，这样的“纯粹”MVC没有涉及到，因为没有任何内容涉及MVC的任何方面。这些助手纯粹是视图的特征（MVC中的V）。 – 2013-05-19 07:12:49
佣工绝对没有错。他们习惯于保持你的观点清晰和声明。有一种说法就像“如果在你的观点中有”如果“陈述，你做错了”。它们被用在许多着名的MVC框架中，比如Ruby On Rails和Cake PHP。退房this post。 “纯粹主义”与否，助手是一件好事，不要被混淆与不良练习或抽象漏洞。
我认为其他人没有提到的重要一点是您的意见的可移植性。
您可以立即将您的HTML，JavaScript和CSS移动到其他平台上的应用程序。您不必将所有丑陋的HTMLHiders转换。对不起，HTMLHelpers ..转换为实际的HTML。
尽管我非常重视.NET框架，它减少了我的开发时间，使我的工作变得简单，但我强烈认为视图应该是非专有的。
无论如何，您可以从模型和控制器的框架中获得几乎所有的好处。在您的表示层注入框架的依赖关系完全没有价值，IMO。
不需要。只要帮手没有违反MVC的关注点，那就是他们正在做的不是表现逻辑，那么他们没有任何问题。是的，一些复杂的助手实际上可能会违背顾虑的分离，但这与助手本身是好还是不好有所不同。 – 2013-05-19 07:16:59