我们更喜欢以哪种方式在MVC中创建表单？

<% Html.Form() { %>
<% } %>

或者

<form action="<%= Url.Action("ManageImage", "UserAccount") %>" method="post">
</form>

我知道从PR5开始的Html.Form()现在仅使用请求提供的URL。但是，与此相关的事情并不适合我，尤其是因为我将获得所有包含的所有查询字符串的全部包bag。

你要做什么？

解决方案

回答

总的来说，我认为我有点老派，因为我更喜欢滚动自己的HTML元素。

我还更喜欢像NHaml这样的视图引擎，它使编写HTML几乎简单了一个数量级。

回答

当然，第二种方式。第一种方法是以程序员为中心的，这与MVC的V部分无关。第二种方法是以设计者为中心的，仅在必要时绑定到模型，使HTML尽可能自然。

回答

我必须同意你们两个，我不是很喜欢这种似乎将其方式集成到MVC中的简单化WebForms样式。这些东西几乎看起来应该是第3方库，或者至少是扩展库，如果需要或者需要，可以包含这些库。

回答

我完全认为老式HTML是设计人员使用的HTML。由于这个原因，我不想包含太多以代码为中心的语法。我将Web表单视图引擎视为第三方库，因为我将其替换为其他视图引擎。如果我们不喜欢Web表单视图模型的工作方式或者前进方向，则可以始终采用其他方法。这是我喜欢ASP.NET MVC的主要原因之一。

回答

使用辅助程序的原因是，它们允许我们以一致且DRY的方式封装常见模式。就像使用常规代码一样，将它们视为重构视图以消除重复的一种方式。

例如，我在博客中介绍了一些RESTful NHaml帮助器，它们可以基于模型构建URL。

回答

我同意安德鲁·彼得斯(DRY)的观点。还应该指出，我们可以为.Form()帮助器指定控制器，操作和参数，如果它们适合路由规则，则将不使用查询字符串参数。

我也了解Will将对MVC中的V所说的话。我认为，只要将代码放在视图中，就不会在视图中放置代码。如果不小心的话，很容易跨越控制器和视图之间的界线。就我个人而言，我不能忍受不让我的眼睛流血或者想要谋杀某人的冲动来使用Cas模板引擎。这可以帮助我保持逻辑分离，C＃中的控制器逻辑，brail中的视图逻辑。