在视图中使用常规 HTML，是好的还是不好的实践？

Question

作为一个对使用HTML感到自在的人，我发现在我的视图中直接使用常规的HTML更容易，例如：使用<input type="text" maxlength="30" name="firstname">创建文本框，而不是使用<% html.textbox("firstname") %>或者使用<form method="post" name="myform">代替<% html.beginform() { %>。

这种方式被认为是不好的实践吗？ 我应该开始强迫自己使用辅助方法吗？ 如果我继续使用常规的html，是否会遇到问题？

这只是我想知道的一些事情，因为我在网上看到的大多数示例和材料都使用了之前提到的所有辅助方法和技术。

- Morph

---

这个特定于MVC还是适用于asp.net整体？ - Joe Phillips

我猜这个问题适用于大多数试图“抽象化”HTML并使用控件、助手等的编程语言/框架。但我在ASP.NET MVC中的视图上下文中提出了这个问题，但我想它可以扩展到其他情境中。 - Morph

@Morph，自你最初的帖子以来已经过去了3年，你是否发现自己在视图中编写更多的HTML或辅助代码？ - Ray Cheng

@RayCheng 我不经常编写辅助程序，只在非常专业的场合下使用。通常只使用HTML或内置的MVC辅助程序！ - Morph

Answer 1

我在PHP中使用自定义表单助手来创建输入字段。对于一些快速的任务，它们很方便，但是当您需要在元素上执行一些非常规操作（添加一些事件和JavaScript、嵌入内联样式、禁用它）时，助手函数会成为干扰。我更喜欢使用真实的HTML，因为最终它就是这个。

- tkotitan

Answer 2

出于各种原因，我经常使用原始的HTML，并且只在我的标签中加入runat="server"属性，以便从我的类中访问它们。

ASP.NET控件非常棒，但是经过一段时间后，人们（也许只有我）通常会发现它们会妨碍你的进度，特别是在高级场景或者做一些高级Javascript时。更不用说viewstate了，在一个中等大小带有一些数据的页面上，它很容易就能占据一半甚至更多的空间。使用原始的HTML可以更好地控制你的页面。

所以这可能听起来有点奇怪，但在使用ASP.NET控件一段时间后，我已经回到了（主要是）使用原始的HTML。这有点像使用一些非常好的所见即所得编辑器，然后意识到实际上需要更多的努力才能完成高级任务，比如使用记事本之类的工具。

- DrJokepu

Answer 3

编写HTML代码本身并不是不良的做法。当比较两者时，自己编写需要按照您所需的方式编写HTML，而使用预制函数时，函数会根据它们认为合适的方式生成HTML。我认为如果您对元素有多少控制取决于后者是否要走向不良的做法。显然，有些是可以接受的，但我发现其中很大一部分函数只会导致代码膨胀和/或标记混乱。

- Andrew G. Johnson

Answer 4

这其实是一个实用主义的选择，但线索就在名字里——它们不是无缘无故被称为“helpers”的。

• 如果你只是做简单的标记，那么可以使用原始的HTML。
• 如果你正在做可能会因为路由规则重构等原因而发生变化的事情，那么使用helper，它将负责响应这些变化。一个很好的例子是“BeginForm” helper。

像生活中的大多数事情一样，要运用常识。

- belugabob

Answer 5

Html助手将帮助您动态创建HTML。如果您决定重命名控制器，则Html.BeginForm会自动为您输出正确的actionurl（某些重载比其他重载更具动态性）。如果您硬编码了actionurl，那么您当然需要进行更多的代码更改。这对于Htmlhelper和Webform控件都是正确的。它们只是更加动态。在许多情况下，它们只是为您节省了大量重复的HTML代码，例如MVC网格或GridView。

- TT

Answer 6

当我第一次使用MVC时，我尝试使用Html Helpers甚至创建自己的helpers。然而，当我尝试在我的应用程序中使用JQuery / Ajax时，我倾向于使用更多的原始HTML。我认为使用原始HTML并不是一个坏习惯。如果你想在客户端有更多的控制权，对我来说，原始HTML似乎是更容易的方式。

- kimsk