除了我，还有人不懂 ASP.NET MVC 吗？

NET MVC 的实现非常糟糕。这个产品简直糟透了。我已经看过几个关于它的演示，我为 MSFT 感到羞愧... ... 我确信写它的家伙比我聪明，但它几乎就像是他们不知道什么是模型-视图-控制器。

我所知道的试图实现 MVC 的人只有那些喜欢尝试 MSFT 新事物的人。在我看过的演示中，主持人的语气带着歉意。

我是 MSFT 的忠实粉丝，但我不得不说，我没有理由为他们的 MVC 实现而烦恼。无论是使用 Web 表单还是使用 jquery 进行 Web 开发，都不要选择这种令人厌恶的方式。

编辑:

模型-视图-控制器体系结构设计模式的目的是将域从表示从业务规则中分离出来。我已经在我实现的每个 Web 窗体项目中成功地使用了该模式。NET MVC 产品并不适合实际的架构设计模式。

MVC 使您能够更好地控制输出，并且随之而来的是编写设计拙劣的 HTML、标签汤等等的风险。.

但与此同时，你有了几个以前没有的新选择。

1. 对页面和页面内元素的更多控制
2. 减少输出中的“垃圾”，比如元素 (别误会，我喜欢 ViewState)上的 ViewState 或过长的 ID
3. 更好地使用 Javascript 进行客户端编程(Web 2.0应用程序，有人知道吗?)
4. 不只是 MVC 还有 JsonResult 很狡猾..。

这并不是说你不能使用 WebForms 来做这些事情，但是 MVC 让它变得更简单。

当我需要快速创建 Web 应用程序时，我仍然使用 WebForms，因为我可以利用服务器控件等。WebForms 隐藏了输入标记和提交按钮的所有细节。

如果您粗心大意，WebForms 和 MVC 都会产生绝对的垃圾。和往常一样，仔细的计划和深思熟虑的设计将导致一个高质量的应用程序，无论它是 MVC 还是 WebForms。

[更新]

如果这也算是一种安慰的话，那就是 MVC 只是微软的一种新的、不断发展的技术。已经有很多帖子，WebForms 不仅将保留，而且将继续开发..。

Http://haacked.com

Http://www.misfitgeek.com

Http://rachelappel.com

诸如此类。

对于那些担心的路线 MVC 是采取，我建议给“家伙”你的反馈。到目前为止，他们似乎都在监听！

我不确定人们是从什么时候开始不再关心他们的代码的。

HTML 是最公开的显示你的工作，有很多开发人员谁使用记事本，记事本 + + ，和其他纯文本编辑器建立了很多网站。

MVC 是关于从 Web 表单中获得控制，在无状态环境中工作，以及实现模型视图控制器设计模式，而不需要通常在该模式的实现中进行的所有额外工作。

如果你想要控制，清理代码，使用 MVC 设计模式，这是为你准备的，如果你不喜欢使用标记，不关心你的标记有多畸形，那么使用 ASP.Net Web Forms。

如果您不喜欢其中任何一个，那么您肯定会在标记中做同样多的工作。

剪辑 我还应该说明 Web Forms 和 MVC 有它们的位置，我绝不是说一个比另一个好，只是说每个 MVC 都有重新控制标记的能力。

我觉得你遗漏了一些东西。首先，不需要回应。写，你可以使用 <%= %>标签。其次，您可以编写自己的 HtmlHelper 扩展来执行常见操作。第三，一点点格式化会有很大帮助。第四，所有这些可能都会停留在一个用户控件中，以便在几个不同的视图之间共享，因此主视图中的总体标记更加清晰。

我承认，标记仍然不像人们希望的那样整洁，但是通过使用一些临时变量，它可以得到相当大的清理。

现在，这不是那么糟糕，如果我不需要格式化它，那就更好了。

 <%
var PreviousPost = ViewData.Model.PreviousPost;
var NextPost = ViewData.Model.NextPost;


// Display the "Next and Previous" links
if (PreviousPost != null || NextPost != null)
{
%>


<div>


<%= PreviousPost == null
? string.Empty
: Html.ActionLinkSpan("<< " + PreviousPost.Subject,
"view",
new { id = PreviousPost.Id },
new { style = "float: left;" } ) %>
<%= NextPost == null
? string.Empty
: Html.ActionLinkSpan( NextPost.Subject + " >>",
"view",
new { id = NextPost.Id },
new { style = "float: right;" } ) %>


<div style="clear: both;" />
</div>


<% } %>

MVC 的重要之处在于它是一个已经存在了很长时间的概念框架，而且它已经证明自己是一个高效、强大的方式来构建横向和纵向扩展的 web 应用程序和工作站应用程序。直接回到 Alto 和 Smalltalk。微软迟到了。我们现在使用的 ASP.NET MVC 非常原始，因为有太多的事情要做; 但该死的，他们正在快速而疯狂地发布新版本。

Ruby on Rails 有什么大不了的？Rails 是 MVC。开发人员一直在转换，因为通过口口相传，它已经成为程序员提高生产力的方式。

这是一件大事; MVC 和 jQuery 的默认是微软接受平台中立至关重要的转折点。它的中立之处在于，与 Web 窗体不同，微软不能在概念上将你锁定。你可以把所有的 C # 代码完全用另一种语言来重新实现(比如说 PHP 或者 java ——你能想到的) ，因为可移植的是 MVC 概念，而不是代码本身。(想象一下，你可以把你的设计作为一个工作站应用程序来实现，只需要很少的代码变化，而且没有设计变化，这是多么巨大的一件事。尝试使用 Web 窗体。)

微软已经决定 Web 窗体不会成为下一个 VB6。

与 Web Forms 相比，MVC 同时是一种较低级的 HTML 生成方法，对页面输出 还有具有更大的控制权，是一种更高级、更受体系结构驱动的方法。让我来捕捉 Web Forms 和 MVC，并说明为什么我认为在许多情况下这种比较更有利于 Web Forms ——只要您不落入一些经典的 Web Forms 陷阱。

网上表格

在 Web 窗体模型中，页直接对应于来自浏览器的页请求。因此，如果您将用户引导到一个 Books 列表，那么您可能在某个地方有一个名为“ Booklist.aspx”的页面，您可以将用户引导到该页面。在这个页面中，您必须提供显示该列表所需的所有内容。这包括提取数据、应用任何业务逻辑和显示结果的代码。如果有任何体系结构或路由逻辑影响页面，您还必须在页面上编写体系结构逻辑。很好 Web Forms 开发通常涉及在单独的(可单元测试的) DLL 中开发一组支持类。这些类将处理业务逻辑、数据访问和体系结构/路由决策。

车祸

MVC 对 Web 应用程序开发采取了一种更“架构”的观点: 提供一个标准化的脚手架，在此基础上进行构建。它还提供了在已建立的体系结构中自动生成模型、视图和控制器类的工具。例如，在 Ruby on Rails (从现在开始就是“ Rails”)和 ASP.NET MVC 中，你总是从一个目录结构开始，这个目录结构反映了他们的 web 应用架构的整体模型。要添加一个视图、模型和控制器，您将使用一个命令，比如 Rails 的“ Rails script/generatefricold { model }”(ASP.NET MVC 在 IDE 中提供了类似的命令)。在生成的控制器类中，将有用于 Index (Show list)、 Show、 New 和 Edit and Destroy (至少在 Rails 中，MVC 是类似的)的方法(“ Actions”)。默认情况下，这些“获取”操作只是捆绑模型并路由到“ View/{ Model name }”目录中相应的视图/html 文件(注意，还有创建、更新和销毁操作来处理“ Post”并路由回 Index 或 Show)。

在 MVC 中，目录和文件的布局是非常重要的。例如，在 ASP.NET MVC 中，“ Book”对象的 索引方法可能只有一行: “ Return View () ;”通过 MVC 的魔力，这将把 Book 模型发送到“/View/Books/Index.aspx”页面，在那里你可以找到显示 Books 的代码。Rails 的方法是类似的，尽管其逻辑更加明确，也没有那么“神奇”MVC 应用程序中的 观景页面通常比 Web Forms 页面更简单，因为它们不必担心路由、业务逻辑或数据处理。

比较

MVC 的优势在于它有一个干净的关注点分离，以及一个更清晰、更以 HTML/CSS/AJAX/Javascript 为中心的模型来生成你的输出。这增强了可测试性，提供了更标准化的设计，并为更“ Web 2.0”类型的网站打开了大门。

然而，也有一些明显的缺点。

首先，虽然很容易建立一个演示站点，但是整个架构模型有一个明显的学习曲线。当他们说“约定优于配置”的时候，听起来不错——直到你意识到你有一本书值得学习。此外，弄清楚发生了什么往往有点令人恼火，因为 是依赖于神奇的调用而不是明确的调用。例如，上面的“ Return View () ;”调用？完全相同的调用可以在其他行动中找到，但 他们去不同的地方。如果你了解 MVC 大会，那么你就知道为什么这样做。然而，它当然不能作为一个好的命名或容易理解的代码的例子，而且对于新的开发人员来说，它比 Web Forms 更难掌握(这不仅仅是观点: 我有一个暑期实习生去年学习了 Web Forms，今年学习了 MVC，生产效率的差异是显而易见的——有利于 Web Forms)。顺便说一句，Rails 在这方面稍微好一点，尽管 Ruby on Rails 的特色是动态命名的方法，这些方法也需要认真适应。

其次，MVC 隐式地假设您正在构建一个典型的 CRUD 风格的网站。架构决策，特别是代码生成器都是为了支持这种类型的 web 应用而构建的。如果您正在构建 CRUD 应用程序，并且希望采用经过验证的体系结构(或者只是不喜欢体系结构设计) ，那么您可能应该考虑 MVC。然而，如果你要做的不仅仅是 CRUD 和/或者你对架构有足够的能力，那么 MVC 可能会让你觉得像一件紧身衣，直到你真正掌握了底层的路由模型(这比简单地在 WebForms 应用中路由要复杂得多)。即便如此，我还是觉得自己一直在与模式作斗争，担心意想不到的结果。

第三，如果你使用 我不喜欢 Linq(要么是因为你害怕 Linq-to-SQL 将会消失，要么是因为你发现 Linq-to-Entity 的生产过剩和供电不足，这很可笑) ，那么你也不想走这条路，因为 ASP.NET MVC 脚手架工具是围绕 Linq 构建的(这对我来说是杀手)。与具有 SQL 经验的人(尤其是精通 TSQL 和存储过程的人)相比，Rails 的数据模型也相当笨拙.

第四，MVC 的支持者经常指出，MVC 视图在精神上更接近于 web 的 HTML/CSS/AJAX 模型。例如，“ HTML Helpers”——视图页面中的小代码调用，交换内容并将其放入 HTML 控件中——与 Javascript 集成要比 Web Forms 控件容易得多。然而，ASP.NET 4.0引入了对控件命名的能力，从而在很大程度上消除了这一优势。

第五，MVC 纯粹主义者经常嘲笑 Viewstate。在某些情况下，他们这样做是正确的。然而，Viewstate 也可以是一个很好的工具，有利于提高生产力。相比之下，处理 Viewstate 要比试图在 MVC 应用程序中集成第三方 Web 控件容易得多。虽然控制集成对于 MVC 来说可能会变得更容易，但是我目前看到的所有努力都是因为需要构建(有些令人厌恶的)代码来将这些控制链接回视图的 Controller 类(也就是——到 解决问题的 MVC 模型)。

结论

我在很多方面都喜欢 MVC 开发(尽管我更喜欢 Rails 而不是 ASP.NET MVC)。我还认为，重要的是我们不要陷入认为 ASP.NET MVC 是 ASP.NET Web Forms 的“反模式”的陷阱。它们是不同的，但并非完全陌生，当然两者都有发展的空间。

然而，我更喜欢 Web Forms 开发，因为 大多数任务更容易完成工作(生成一组 CRUD 表单是个例外)。在某种程度上，MVC 似乎也受到了 过度的理论。的影响。事实上，看看那些了解面向页面的 ASP.NET 但正在尝试 MVC 的人在 SO 上提出的许多问题。毫无例外，当开发人员发现他们不能完成基本的任务而不跳过一些难题或者忍受一个巨大的学习曲线时，他们会咬牙切齿。在我的书中，正是 这个使得 Web Forms 优于 MVC: MVC 让你支付一个 真实世界的价格来获得更多的可测试性，或者更糟糕的是，仅仅因为你使用的是 最新科技。而被看作是 酷

更新: 我在评论部分受到了严厉的批评——其中一些相当公平。因此，我花了几个月的时间学习 Rails 和 ASP.NET MVC，只是为了确保我不会真的错过下一个大事件！当然，它也有助于确保我对这个问题作出平衡和适当的回答。您应该知道，上面的回复是对我最初的回答的重大改写，以防评论似乎不同步。

当我更仔细地研究 MVC 的时候，我想，有那么一会儿，我会以一个重大的过失而告终。最后，我得出结论，虽然我认为我们需要在 Web Forms 架构和可测试性上花费更多的精力，但是 MVC 确实没有响应我的号召。所以，衷心感谢那些对我最初的回答提出了明智批评的人们。

至于那些将此视为 宗教战争的人，以及那些不遗余力地设计下调投票洪流的人，我不明白你为什么要费心(在多个场合，20多张下调投票在几秒钟内相继出现肯定是不正常的)。如果你正在阅读这个答案，并且想知道我的答案是否真的有什么“错误”，因为我的得分远远低于其他一些答案，请放心，它更多地说明了一些人的不同意见，而不是社区的普遍意义(总的来说，这个问题已经得到了100多次的支持)。

事实上，许多开发人员并不关心 MVC，事实上，这并不是少数人的观点(甚至在微软内部，正如博客所指出的那样)。

我承认我还没有得到 asp.net 的 MVC。我试着把它用在我正在做的一个副项目中，但是进展很慢。

除了不能在 Web 表单中做那些容易做的事情之外，我还注意到了标签汤。从这个角度来看，似乎的确是倒退了一步。我一直希望，随着我的学习，情况会好转。

到目前为止，我注意到使用 MVC 的首要原因是获得对 HTML 的完全控制权。我还读到 asp.net MVC 能够提供比 web 表单更快的页面，可能与此有关，单个页面的大小比一般的 web 表单页面要小。

我真的不关心我的 HTML 看起来像什么，只要它在主要的浏览器中工作，但我确实关心我的页面加载速度有多快，它们占用了多少带宽。

嘿，我也一直在纠结要不要换成 MVC。我绝对不是经典的 ASP 和 MVC 渲染的粉丝，这让我想起了很多那些日子。然而，我越多地使用 MVC，它就越适合我。我是一个喜欢 webform 的人(很多人都是) ，在过去的几年里，我已经习惯了使用数据网格等等。车祸被带走了。HTML 助手类就是答案。

就在最近，我花了两天的时间试图找出在 MVC 中添加分页到“网格”的最佳方法。现在，有了网络表单，我可以马上把它拿出来。但是我要说的是... ... 一旦我为 MVC 构建了分页助手类，实现起来就变得非常简单了。对我来说，甚至比网络表单更容易。

也就是说，我认为当有一套一致的 HTML Helpers 时，MVC 将会对开发人员更加友好。我认为在不久的将来，我们将会看到大量的 HTML 助手类出现在网络上。

自从 Preview 3发布以来，我一直在使用 MVC，尽管它仍然有成长的烦恼，但它在团队开发领域帮了不少忙。试着让三个人在同一个网页上工作，然后你就会明白撞墙的概念。我可以与一个开发人员谁理解的设计元素在视图页面和我们的居民 Linq 上帝在使模型工作，而我把一切都在控制器。我从来没有在一个关注点分离如此容易达到的领域里成长。

ASP.Net MVC-StackOverflow 在 MVC 堆栈上运行。最大的卖点

也就是说... ... 您的代码比我通常对视图页面所做的要漂亮得多。另外，我的一个同事正在将 HTML 助手封装到一个标记库中。而不是 <% = Html。这里()% > 它的工作原理类似于

< hh: Random function/>

我只是希望 MVC 团队在某个时候能够解决这个问题，因为我相信他们会做得更好。

<% if (Model.PreviousPost || Model.NextPost) { %>
<div class="pager">
<% if (Model.PreviousPost) { %>
<span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
<% } if (Model.NextPost) { %>
<span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
<% } %>
</div>
<% } %>

您可以发表另一篇文章询问如何做到这一点，而不包括嵌入的 CSS。

注意: ViewData.Model 在下一个版本中变成了 Model。

在用户控件的帮助下，这将成为

<% Html.RenderPartial("Pager", Model.PagerData) %>

其中 PagerData 是通过操作处理程序中的匿名构造函数初始化的。

Edit: 对于这个问题，我很好奇您的 WebForm 实现会是什么样子。

虽然我完全同意这是一个丑陋的标记，但是我认为使用丑陋的视图语法来抹杀 ASP.NET MVC 作为一个整体是不公平的。视图语法从微软那里得到的关注最少，我完全期待不久之后能有所作为。

其他的答案已经讨论了 MVC 作为一个整体的好处，所以我将重点关注视图语法:

鼓励使用 Html。ActionLink 和其他生成 HTML 的方法是朝着错误方向迈出的一步。这有点服务器控制的味道，对我来说，这是在解决一个根本不存在的问题。如果我们要从代码中生成标记，那么为什么还要麻烦地使用 HTML 呢？我们可以只使用 DOM 或其他模型，并在控制器中构建内容。好吧，听起来很糟糕，不是吗？哦，是的，关注点分离，这就是为什么我们有一个观点。

我认为正确的方向是使视图语法尽可能像 HTML。请记住，一个设计良好的 MVC 不仅应该让你的代码从内容中分离出来，它应该让你的生产流线化，让那些在视图布局工作方面的专家(即使他们不知道 ASP.NET) ，然后作为一个开发人员，你可以介入，使视图样机实际上是动态的。只有当视图语法看起来非常像 HTML 时才能做到这一点，以便布局人员可以使用 DreamWeaver 或当前流行的布局工具。您可能同时构建几十个站点，并且需要以这种方式进行扩展以提高生产效率。让我举一个例子来说明我是如何看待“语言”这个观点的:

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
<a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span>
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
<a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span>
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

这有几个好处:

• 看起来好多了
• 更简洁
• 在 HTML 和 <% > 标记之间没有时髦的上下文切换
• 易于理解的关键字是不言自明的(即使是非程序员也可以做到这一点-有利于并行化)
• 尽可能多的逻辑回到控制器(或模型)中
• 没有生成 HTML-同样，这使得人们很容易进入并知道在哪里设置样式，而不必使用 HTML。方法
• 当你在浏览器中以纯 HTML 的形式加载视图时，代码中包含了样本文本(同样，对于布局人员来说也是好的)

那么，这个语法到底是做什么的呢？

Inner = “”-无论引号中是什么，都会得到计算，标记的内部 HTML 将被替换为结果字符串。(我们的示例文本被替换)

Out = “”-引号中的内容将被计算，标记的外部 HTML 将被替换为结果字符串。(同样，示例文本将被替换。)

{}-这用于在属性中插入输出，类似于 <% =% >

If = “”-在 qoutes 内部是要求值的布尔表达式。If 的结尾是关闭 HTML 标记的地方。

否则

Mcv: elseif =””-..。

Foreach

有趣的是，我第一次看到网络表单时也是这么说的。

对 ASP.NET MVC 的大多数反对意见似乎都集中在视图上，视图是体系结构中最“可选”和最模块化的部分之一。NVelocity、 NHaml、 火花、 XSLT 和其他视图引擎都可以是 很容易就换掉了(而且每次发布都变得越来越简单)。其中许多具有更简洁的语法，用于执行表示逻辑和格式化，同时仍然可以完全控制发出的 HTML。

除此之外，几乎所有的批评似乎都归结于默认视图中的 <% > 标签，以及它有多么“丑陋”。这种观点通常植根于 WebForms 方法，它只是将大多数经典的 ASP 丑陋移动到代码隐藏文件中。

即使没有做代码隐藏“错误”，您也会遇到类似“中继器中的 OnItemDataBound”这样的问题，它在美学上比“标签汤”更难看，即使只是以一种不同的方式。Foreach 循环可以更容易阅读，即使在循环的输出中嵌入了变量，特别是如果您使用的是其他非 ASP.NET 技术的 MVC。理解 foreach 循环所需的 Google-fu 要少得多，而理解修改中继器中某个字段的方法就是干扰 OnItemDataBound (以及检查是否正确更改该元素的老鼠巢)。

ASP 标签驱动的“意大利面条”最大的问题在于将数据库连接等内容直接插入 HTML 之间。

碰巧使用 <%% > 这样做只是与经典 ASP 的意大利面条本质有关，而不是因果关系。如果您将视图逻辑保留为 HTML/CSS/Javascript，并且只保留执行 展示所需的最小逻辑，那么剩下的就是语法了。

当将给定的功能与 WebForms 进行比较时，请确保包含所有设计器生成的 C # 和代码隐藏 C # 以及。Aspx 代码，以确保 MVC 解决方案实际上并不简单。

当与对可重复的表示逻辑位的部分视图的明智使用相结合时，它真的可以很漂亮和优雅。

就个人而言，我希望早期的教程内容更多地关注这一方面，而不是仅仅关注测试驱动、控制反转等。虽然专家们反对的是其他东西，但是战壕里的人们更有可能反对“标签汤”。

无论如何，这是一个仍处于测试阶段的平台。尽管如此，与大多数微软测试版技术相比，它获得了更多的部署和非微软开发人员使用它构建实际的东西。因此，这种嗡嗡声往往使它看起来比它周围的基础设施(文档、指导模式等)更进一步。在这一点上真正可用只是放大了这种效果。

JavaEE 的 JSP 在第一次被提出时就是这样的——丑陋的 scriptlet 代码。

然后，他们提供了标记库，使它们更像 HTML 标记。问题是任何人都可以编写标记库。有些结果是灾难性的，因为人们在生成 HTML 的标记库中嵌入了大量的逻辑(甚至样式)。

我认为最好的解决方案是 JSTL (JSTL)。它是“标准的”，HTML 标签式的，并且有助于防止人们将逻辑放入页面中。

一个额外的好处是，它保留了 Web 设计师和开发人员之间的界限。我所看到的好的网站都是由具有审美意识和可用性设计的人设计的。他们布局页面和 CSS，并将其传递给开发人员，开发人员添加动态数据位。作为一个缺乏这些天赋的开发人员，我认为当我们要求开发人员从头到尾地编写网页时，我们放弃了一些重要的东西。Flex 和 Silverlight 也会遇到同样的问题，因为设计师不太可能很好地了解 JavaScript 和 AJAX。

如果.NET 有一条类似于 JSTL 的路径，我建议他们研究一下。

与网上表格相比，ASP.NET MVC Framework 的两个主要优点是:

1. 可测试性 -web 表单中的 UI 和事件几乎不可能进行测试。使用 ASP.NET MVC，单元测试控制器操作及其呈现的视图非常简单。这需要预先支付开发成本，但研究表明，从长远来看，重构和维护应用程序是值得的。
2. 更好地控制呈现的 HTML -您声明您不关心呈现的 HTML，因为没有人看它。如果这是正确格式化 HTML 的唯一原因，那么这是一个有效的抱怨。需要正确格式化 HTML 的原因有很多，包括: SEO，能够更频繁地使用 id 选择器(在 css 和 javascript 中) ，由于缺少视图状态和长得可笑的 id (ctl00 _ etcetcetc)而导致页面占用较小。

现在，这些原因并没有真正使 ASP.NET MVC 在某种程度上比 Web 表单更好或更差。NET MVC 有它的优点和缺点，就像 web 表单一样。然而，大多数对 ASP.NET MVC 的抱怨似乎源于对如何使用它的缺乏理解，而不是框架中的实际缺陷。你的代码感觉不对或者看起来不对的原因可能是因为你有几年的 web 表单经验，而且只有1-2个月的 ASP.NET MVC 经验。

这里的问题并不是 ASP.NET MVC 有多棒或者有多糟糕，而是它是新的，对于如何正确使用它几乎没有什么共识。NET MVC 对应用程序中发生的事情提供了更细粒度的控制。这可以使某些任务更容易或更难，取决于您如何处理它们。

我不能直接与 ASP.NET MVC 项目对话，但是一般来说，MVC 框架已经开始主导 网应用程序开发，因为

1. 它们提供了数据库操作、“业务逻辑”和表示之间的正式分离

2. 它们在视图中提供了足够的灵活性，允许开发人员调整他们的 HTML/CSS/Javascript 以便在多种浏览器 以及这些浏览器的未来版本中工作

最后一点才是最重要的。使用 Webform 和类似的技术，您可以依赖供应商为您编写 HTML/CSS/Javascript。它非常强大，但是你不能保证当前版本的 Webform 能够与下一代浏览器兼容。

这就是风景的力量。您可以完全控制应用程序的 HTML。缺点是，你需要有足够的纪律性，以便将视图中的逻辑保持在最低限度，并尽可能使模板代码保持简单。

所以，这就是权衡。如果网络表单适合你，而 MVC 不适合，那么 继续使用网上表格

使用门面模式来包装所有需要显示的数据的逻辑，然后在视图中将其作为通用数据使用，然后..。没有意大利面条代码了。 Http://en.wikipedia.org/wiki/design_pattern_(computer_science)

如果你需要更多帮助 cgardner2020@gmail.com

我最大的挫折就是不知道如何“恰当地”做事。自从它作为预览版发布以来，我们都花了一些时间来看一些东西，但是它们已经发生了相当大的变化。起初我真的很沮丧，但是这个框架似乎足够可行，使我能够很快地创建非常复杂的 UI (读取: Javascript)。我明白你可以这样做，因为我以前这样做，但它是一个巨大的痛苦的屁股试图得到一切渲染正确。很多时候，我最终会使用一个中继器来控制精确的输出，最终会得到很多意大利面条的混乱，你也有以上。

为了避免同样的混乱，我一直在使用域、服务层和 dto 的组合来传输视图。再加上火花，一个视觉引擎，真的很不错。安装需要一些时间，但是一旦开始安装，我已经看到我的应用程序的复杂性在可视化方面有了很大的提高，但是代码方面的问题简单得令人讨厌。

我可能不会这样做，但这是你的例子:

<if condition="myDtp.ShowPager">
<div>
<first />
<last />
<div style="clear: both;" />
</div>
</if>

这是相当可维护的，可测试的，并且在我的代码汤中尝起来很美味。

总而言之，干净的代码确实是可能的，但这是一个巨大的屁股从我们做事情的方式转变。不过我觉得还没人明白。我知道我还没弄明白。

请看看罗布 · 康纳利的文章 我想我只能说: 你应该学习 MVC

Steve Sanderson 最近出版的书《 Pro ASP.NET MVC 》[1][2]提出了另一种选择——创建一个定制的 HtmlHelper 扩展。他的例子(来自110页的第4章)使用了一个分页列表的例子，但它可以很容易地适应您的情况。

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
StringBuilder result = new StringBuilder();


if (previous != null || next != null)
{
result.Append("<div>");


if (previous != null)
{
result.Append(@"<span class=""left"">");
TagBuilder link = new TagBuilder("a");
link.MergeAttribute("href", pageUrl(previous.Id));
link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
result.Append(link.ToString());
result.Append("</span>");
}


if (next != null)
{
if (previous != null)
{
result.Append(" ");
}


result.Append(@"<span class=""right"">");
TagBuilder link = new TagBuilder("a");
link.MergeAttribute("href", pageUrl(next.Id));
link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
result.Append(link.ToString());
result.Append("</span>");
}


result.Append("</div>");
}


return result.ToString();
}

您可以在视图中使用类似下面这样的代码来调用它:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] 翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳翻译: 奇芳 http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

我也是; 我宁愿把时间花在 Silverlight 上，而不是 ASP.NET MVC。 我试过 MVC 1.0，几天前看过最新的2.0 Beta 1版本。

我不觉得 ASP.NET MVC 比 webform 好。 MVC 的卖点是:

1. 单位(测试)
   
2. 分离设计(视图)和逻辑(控制器 + 模型)
   
3. 没有视图状态和更好的元素 ID 管理
   
4. RESTful URL 等等..。

但是 webform，通过使用代码隐藏。主题，皮肤和资源已经完美地分离了设计和逻辑。

Viewstate: 客户端 ID 管理将在 ASP.NET 4.0上实现。我只关心单元测试，但单元测试不足以成为我从 webform 转向 ASP.NET MVC 的理由。

也许我可以说: ASP.NET MVC 不错，但 webform 已经足够了。

现在，我只能代表我自己说:

我的意思是，如果你是一个死硬(任何东西) ，那么转换不是为你。如果你喜欢 WebForms，那是因为你可以完成你需要完成的任务，这也是任何人的目标。

Webform 在从 开发商中抽象 HTML 方面做得很好。如果这是您的目标，那么坚持使用 Web 窗体。你有所有奇妙的“点击和拖动”功能，使桌面开发成为今天的样子。有许多包含的控件(加上大量的第三方控件)可以带来不同的功能。您可以从数据库中拖动与 DataSource 直接关联的“网格”; 它内置了内联编辑、分页等功能。

到目前为止，ASP.NET MVC 在第三方控件方面非常有限。因此，如果您喜欢快速应用程序开发，其中有很多功能是为您连接的，您不应该尝试转换。

说了这么多，这就是 ASP.NET 的亮点: TDD 代码是不可测试的。

• 关注点分离。这是 MVC 模式的骨干。我完全知道您可以在 Web 窗体中实现这一点。然而，我喜欢强加的结构。在 Web 表单中很容易混合设计和逻辑。NET MVC 使团队中的不同成员更容易处理应用程序的不同部分。

• 来自其他地方: 我的背景是 CakePHP 和 Ruby on Rails。所以，我的偏见很明显。只要你觉得舒服就行。

• 学习曲线: 为了扩展最后一点，我讨厌用“模板化”来改变不同元素的功能。我不喜欢这样一个事实，即很多设计都是在文件后面的代码中完成的。当我已经非常熟悉 HTML 和 CSS 的时候，还有一件事情需要学习。如果我想在页面上的“元素”中执行某些操作，我会添加一个“ div”或“ span”，在其上添加一个 ID，然后就可以执行了。在 Web 表单中，我将不得不研究如何做到这一点。

• Web“设计”的现状: jQuery 这样的 Javascript 库正变得越来越普遍。Web 窗体损坏 ID 的方式只会使实现(在 VisualStudio 之外)变得更加困难。

• 更多分离(设计) : 因为很多设计都连接到控件中，所以外部设计师(没有 Web 窗体)很难在 Web 窗体项目中工作。Web Forms 的构建是为了成为最终的一切。

同样，这些原因大多源于我对 Web 表单的不熟悉。一个 Web 窗体项目(如果设计得当)可以拥有 ASP.NET MVC 的“大部分”好处。但这是一个警告: “如果设计正确”。而这正是我不知道如何在 Web 表单中实现的。

如果你在 Web 表单方面做得很出色，那么你的工作效率很高，而且很适合你，这就是你应该留下来的地方。

基本上，对两者做一个快速回顾(试着找到一个没有偏见的来源[祝你好运]) ，列出利弊，评估哪一个适合你的目标，然后根据这个来选择。

底线是，选择阻力最小、收益最大的道路来实现你的目标。Web Forms 是一个非常成熟的框架，未来只会变得更好。NET MVC 只是另一种选择(吸引 Ruby on Rails 和 CakePHP 开发人员，比如我自己: P)

我希望看到一个来自菲尔哈克的帖子，但它不在这里，所以我只是剪切和粘贴从 Http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should-learn-mvc/

只是想我会分享这个样本看起来与闪亮的新 剃刀视图引擎，这是自 ASP 默认。NET MVC 3.

@{
var prevPost = ViewData.Model.PreviousPost;
var nextPost = ViewData.Model.NextPost;
}


@if (prevPost != null || nextPost != null) {
<div>
@if (prevPost != null) {
<span style="float: left;">
@Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
</span>
}
@if (nextPost != null) {
<span style="float: left;">
@Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
</span>
}
<div style="clear: both;" />
</div>
}

有什么问题吗？
此外，您实际上不应该内联您的 CSS 样式，不是吗？你为什么要在三个地方检查是否为无效，而不是只在两个地方？额外的血氧饱和度很少受伤。我是这么做的:

<div>
@if (prevPost != null) {
@Html.ActionLink("<< " + prevPost.Subject, "view",
new { id = prevPost.Id, @class = "prev-link" })
}
@if (nextPost != null) {
@Html.ActionLink(nextPost.Subject + " >>", "view",
new { id = nextPost.Id, @class = "next-link" })
}
<div class="clear" />
</div>