除了我之外，还有谁没有得到ASP.NET MVC吗？[关闭]

自CTP以来，我就一直在摆弄ASP.NET MVC，我喜欢他们做的很多事情，但是有些事情我却没有。

例如，我下载了beta1，并与它一起组成了一个个人网站/简历/博客。这是ViewSinglePost视图的一个片段：

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

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

真恶心！（还请注意，HTML中有临时占位符HTML，一旦功能正常，我将进行实际设计）。

难道我做错了什么？因为我在经典的ASP中度过了很多黑暗的日子，所以这个标签汤使我很想起它。

每个人都讲着如何做更清洁的HTML。你猜怎么了？1％的人查看输出的HTML。对我来说，只要我拥有易于维护的代码，我都不在乎Webforms是否在呈现的HTML中弄乱了我的缩进……不是！

那么，转换我，一个顽固的webforms家伙，为什么我要为此放弃漂亮的ASPX页面？

编辑：粗体的“ temp Html / css”行，以便人们对此st之以鼻。

与Web窗体相比，MVC同时是用于HTML生成的较低级方法，可以更好地控制页面输出，并且是较高级，更受体系结构驱动的方法。让我记录一下Web Forms和MVC，并说明为什么我认为在很多情况下，这种比较偏爱Web Forms的原因-只要您不属于某些经典的Web Forms陷阱。

网络表格

在Web窗体模型中，您的页面直接对应于浏览器的页面请求。因此，如果将用户定向到“书籍”列表，则可能会将页面定向到“ Booklist.aspx”。在该页面中，您必须提供显示该列表所需的一切。这包括用于提取数据，应用任何业务逻辑以及显示结果的代码。如果有任何架构或路由逻辑影响页面，则还必须在页面上编写架构逻辑。 良好的 Web窗体开发通常涉及在单独的（可单元测试的）DLL中开发一组支持类。这些类将处理业务逻辑，数据访问和体系结构/路由决策。

MVC

MVC对Web应用程序开发采取了更为“架构性”的观点：提供了构建标准框架。它还提供了用于在已建立的体系结构内自动生成模型，视图和控制器类的工具。例如，在Ruby on Rails（从这里开始只是“ Rails”）和ASP.NET MVC中，您总是从反映其Web应用程序体系结构总体模型的目录结构开始。要添加视图，模型和控制器，您将使用类似Rails的“ Rails脚本/生成脚手架{modelname}”的命令（ASP.NET MVC在IDE中提供了类似的命令）。在生成的控制器类中，将存在索引（显示列表），显示，新建以及编辑和销毁（至少在Rails中，MVC相似）的方法（“动作”）。默认情况下，这些“

目录和文件的布局在MVC中很重要。例如，在ASP.NET MVC中，“ Book”对象的Index方法可能只有一行：“ Return View（）;”。通过MVC的魔力，这会将Book模型发送到“ /View/Books/Index.aspx”页面，您将在其中找到显示Books的代码。Rails的方法与此类似，尽管逻辑更加明确，“魔术”也少了。MVC应用程序中的“ 视图”页面通常比“ Web表单”页面简单，因为它们不必担心路由，业务逻辑或数据处理。

比较方式

MVC的优点围绕着清晰的关注点分离和更清洁，更HTML / CSS / AJAX /以Javascript为中心的模型来生成输出。这增强了可测试性，提供了更加标准化的设计，并为更多“ Web 2.0”类型的网站打开了大门。

但是，也有一些明显的缺点。

首先，虽然很容易获得演示站点，但总体架构模型具有重要的学习曲线。当他们说“ Convention over Configuration”时，这听起来不错-直到您意识到自己有一本书值得学习的惯例。此外，弄清楚正在发生的事情通常有点令人发疯，因为您是依靠魔术而不是显式调用。例如，“ Return View（）;” 在上面打电话吗？可以在其他操作中找到完全相同的调用，但是它们转到不同的位置。如果您了解MVC约定那么您知道为什么这样做。但是，它肯定不适合作为良好命名或易于理解的代码的示例，对于新开发人员而言，比起Web Forms而言，学习起来要困难得多（这不仅是一种观点：我去年夏天在暑期实习，学习Web Forms。和今年的MVC，生产力方面的差异也很明显-支持Web表单）。顺便说一句，尽管Ruby on Rails具有动态命名的方法，但在某些方面也需要认真使用，但Rails在这方面要好一些。

其次，MVC隐式假定您正在构建经典的CRUD风格的网站。架构决策，尤其是代码生成器，都是为了支持这种类型的Web应用程序而构建的。如果您正在构建CRUD应用程序并且想要采用经过验证的体系结构（或者只是不喜欢体系结构设计），那么您可能应该考虑使用MVC。但是，如果您要做的不只是CRUD，而且/或者您有足够的体系结构能力，那么在您真正掌握基础路由模型之前，MVC可能会像直升飞机一样（这比在WebForms应用程序中简单地路由要复杂得多）。即使那样，我仍然觉得自己一直在与模型争执，并担心意外的结果。

第三，如果您不关心Linq（要么是因为您担心Linq-to-SQL会消失，要么是因为您发现Linq-to-Entities可笑地过度生产且功能不足），那么您也不想因为ASP.NET MVC脚手架工具是围绕Linq构建的（因此对我来说是杀手），所以走了这条路。与您有SQL经验（尤其是精通TSQL和存储过程！）相比，Rails的数据模型也很笨拙。

第四，MVC支持者经常指出，MVC视图在本质上更接近于Web的HTML / CSS / AJAX模型。例如，“ HTML帮助程序”（在您的vew页面中的小代码调用可交换内容并将其放入HTML控件中）与Javascript集成要比Web Forms控件容易得多。但是，ASP.NET 4.0引入了命名控件的功能，因此在很大程度上消除了这一优势。

第五，MVC的纯粹主义者经常嘲笑Viewstate。在某些情况下，他们这样做是正确的。但是，Viewstate还是一个很好的工具，并且可以提高生产力。相比之下，处理Viewstate 比尝试将第三方Web控件集成到MVC应用程序中要容易得多。虽然控件集成对于MVC来说可能会变得更加容易，但是我目前看到的所有努力都需要构建（有点令人讨厌）代码，以将这些控件链接回视图的Controller类（即- 围绕 MVC模型工作） ）。

结论

我从许多方面喜欢MVC开发（尽管从长远来看，我更喜欢Rails而不是ASP.NET MVC）。我还认为，重要的是，不要陷入认为ASP.NET MVC是ASP.NET Web窗体的“反模式”的陷阱。他们是不同的，但并非完全陌生，当然两者都有空间。

但是，我更喜欢Web Forms开发，因为对于大多数任务而言，完成工作更简单（例外是生成一组CRUD表单）。MVC似乎在某种程度上还受制于过多的理论。 确实，看看那些了解面向页面的ASP.NET但正在尝试MVC的人在SO上在这里问的许多问题。无一例外，开发人员发现他们无法完成基本任务，除非跳过箍圈或承受巨大的学习曲线，无一例外。这就是使Web Forms在我的书中优于MVC的原因：MVC使您付出现实的代价，以获取更多的可测试性，或者更糟糕的是，由于您使用的是Web表单而被视为很酷。最新技术。

更新：我在评论部分受到了严厉的批评-其中有些很公平。因此，我花了几个月的时间来学习Rails和ASP.NET MVC，以确保我不会真正错过下一件大事！当然，这也有助于确保我对问题做出平衡而适当的回答。您应该知道上面的回复是我最初回答的主要重写，以防评论看起来不同步。

当我更仔细地研究MVC时，我想了一会儿，我最终会遇到一个主要的问题。最后，我得出的结论是，尽管我认为我们需要在Web Forms架构和可测试性上花费更多的精力，但MVC确实无法满足我的要求。因此，向那些对我的最初回答提出明智批评的人们表示衷心的“谢谢”。

对于那些认为这是一场宗教斗争并无情地设计下注洪水的人，我不明白您为什么要打扰（多次在几秒钟内在20多个下票肯定是不正常的）。如果您正在阅读此答案，并且想知道分数是否远低于其他答案，那么我的答案是否确实存在“错误”，请放心，它说的是一些不同意的人，而不是一般意义上的社区（总的来说，这个社区已被投票100多次）。

事实是，许多开发人员并不关心MVC，实际上，这并不是少数观点（即使在博客中似乎也表明了在MS中）。

MVC使您可以更好地控制输出，并且有了这种控制，编写设计不良的HTML，标记汤等的更大风险也随之增加。

但是同时，您拥有以前没有的几个新选择...

1. 对页面和页面中元素的更多控制
2. 输出中的“垃圾邮件”较少，例如ViewState或元素上的ID太长（不要误会我的意思，我喜欢ViewState）
3. 具有使用Javascript进行客户端编程的更好的能力（Web 2.0 Applications吗？）
4. 不只是MVC，而且JsonResult也很漂亮...

现在，并不是说您不能使用WebForms做任何这些事情，而是MVC使它变得更容易。

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

如果您不小心，WebForms和MVC都具有绝对的垃圾处理能力。与往常一样，无论是MVC还是WebForms，仔细的计划和经过深思熟虑的设计都会产生高质量的应用程序。

[更新]

如果也能得到安慰，MVC只是Microsoft不断发展的一项新技术。有很多帖子，WebForms不仅会保留，而且会继续开发用于...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... 等等...

对于那些关心MVC所走路线的人，我建议给“家伙”您的反馈。到目前为止，他们似乎在听！

对ASP.NET MVC的大多数异议似乎集中在视图上，这些视图是体系结构中最“可选”的模块化位之一。NVelocity，NHaml，Spark，XSLT和其他视图引擎可以轻松换出（每个版本的使用都变得越来越容易）。其中许多具有更简明的语法，用于执行表示逻辑和格式设置，同时仍完全控制所发出的HTML。

除此之外，几乎所有批评似乎都归因于默认视图中的<％％>标记及其“丑陋”程度。这种观点通常源于对WebForms方法的使用，该方法只是将大多数经典的ASP丑陋性转移到了代码隐藏文件中。

即使没有在“错误”后面进行代码隐藏，您在Repeaters中也有类似OnItemDataBound的东西，如果只是以不同的方式，则与“标记汤” 一样在外观上是丑陋的。即使将变量嵌入到该循环的输出中，foreach循环也可以更轻松地读取，特别是如果您从其他非ASP.NET技术中获得MVC。用Google-fu理解foreach循环所花费的时间要比弄清楚修改中继器中的一个字段的方法是弄乱OnItemDataBound（以及检查其是否是正确的元素的老鼠的巢）要少得多。

ASP标记汤驱动的“意大利面条”的最大问题在于，将诸如数据库连接之类的东西直接插入HTML之间。

使用<％％>这样做恰好与经典ASP的意大利面条性质相关，而不是因果关系。如果您将视图逻辑保持在HTML / CSS / Javascript之上，而执行展示所需的最小逻辑，剩下的就是语法。

在将给定的功能与WebForms进行比较时，请确保包括所有由设计师生成的C＃和C＃背后的代码以及.aspx代码，以确保MVC解决方案实际上并没有那么简单。

当结合明智地使用部分视图来实现表示逻辑的可重复位时，它确实可以很好用。

就个人而言，我希望早期的教程内容更多地集中在此方面，而不是几乎完全集中在测试驱动，控制反转等方面。尽管专家们反对这些其他内容，但更容易陷入困境的人反对“标签汤”。

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

<% 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是通过操作处理程序中的匿名构造函数初始化的。

编辑：我很好奇您的WebForm实现看起来像这个问题。

我不确定人们在什么时候停止关心他们的代码。

HTML是您工作中最公开的显示，许多开发人员使用记事本，notepad ++和其他纯文本编辑器来构建许多网站。

MVC的目的是从Web表单中获取控制权，在无状态环境中工作，并实现Model View Controller设计模式，而无需在该模式的实现中通常进行的所有额外工作。

如果您想要控制，清理代码并使用MVC设计模式，这是给您的，如果您不喜欢使用标记，不必在乎标记的格式如何，那么请使用ASP.Net Web Forms。

如果您不喜欢它们，那么您肯定会在标记中做尽可能多的工作。

编辑 我还应该指出，Web窗体和MVC占有一席之地，我丝毫没有说一个比另一个更好，只是说每个MVC都有重新获得对标记的控制权的实力。

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

我会向您保证，标记仍然不如人们希望的那样整洁，但是可以通过使用一些临时变量来对其进行大量清理。

现在，这还不错，如果我不必为SO格式化，那就更好了。

 <%
    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的隐含支持是Microsoft接受平台无关性至关重要的引爆点。而且中立的是，与Web窗体不同，Microsoft无法从概念上锁定您。您可以完全使用所有C＃代码并以另一种语言重新实现（例如，PHP或Java-您将其命名），因为MVC概念是可移植的，而不是代码本身。（并考虑一下，只需很少的代码更改，而无需更改设计，就可以将您的设计并实现为工作站应用程序有多大。请使用Web Forms进行尝试。）

Microsoft已经决定Web窗体将不是下一个VB6。

请看一下罗伯· 康纳里（Rob Conery）的帖子，我想我会说：您应该学习MVC

与Web表单相比，ASP.NET MVC框架的两个主要优点是：

1. 可测试性-Web表单中的UI和事件几乎无法测试。使用ASP.NET MVC，可以轻松地对控制器动作及其呈现的视图进行单元测试。这附带了前期开发成本，但是研究表明，从长远来看，当需要重构和维护应用程序时，这是有回报的。
2. 更好地控制呈现的HTML-您声明自己不关心呈现的HTML，因为没有人看它。如果这是正确格式化HTML的唯一原因，那将是一个有效的投诉。想要正确格式化HTML的原因有很多，包括：SEO，能够更频繁地使用id选择器的功能（在css和javascript中），由于缺少viewstate以及可笑的长id（ctl00_etcetc等）而导致的页面占用空间较小。

现在，这些原因并没有使ASP.NET MVC像黑白形式的Web表单一样好或坏。与Web表单一样，ASP.NET MVC也有其优点和缺点。但是，大多数对ASP.NET MVC的抱怨似乎是由于缺乏对如何使用它的理解，而不是框架中的实际缺陷。您的代码不正确或看起来不正确的原因可能是因为您拥有多年的Web表单经验，而只有1-2个月的ASP.NET MVC经验。

这里的问题并不是ASP.NET MVC摇摇欲坠，而是因为它是新的，关于如何正确使用它几乎没有共识。ASP.NET MVC对应用程序中发生的事情提供了更细粒度的控制。根据您的处理方式，这会使某些任务更容易或更难。

嘿，我也一直在努力转向MVC。我绝对不喜欢经典的ASP和MVC渲染，这让我想起了很多日子。但是，我使用MVC越多，它对我的​​影响就越大。我是一个webforms的人（和很多人一样），过去的几年中我习惯了使用datagrids等。随着MVC被带走了。HTML Helper类就是答案。

就在最近，我花了两天的时间试图找出在MVC中向“网格”添加分页的最佳方法。现在，有了网络表单，我很快就能解决这个问题。但是我要说的是...一旦为MVC构建了页面帮助程序类，它的实现就变得非常简单。对我来说，甚至比网络表单还容易。

话虽这么说，但我认为，如果有一致的HTML Helper集，MVC将对开发人员更加友好。我认为我们将开始在不久的将来在网络上弹出大量HTML帮助器类。

这很有趣，因为这是我第一次看到网络表单时所说的。

我承认我还没有获得asp.net MVC。我正在尝试在正在做的辅助项目中使用它，但是进展非常缓慢。

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

到目前为止，我已经注意到使用MVC的首要原因是要完全控制HTML。我还阅读到asp.net MVC能够比Web表单更快地提供更多页面，并且可能与此相关，单个页面的大小小于平均Web表单页面。

我真的不在乎我的HTML是什么样的，只要它可以在主要的浏览器中运行就可以了，但是我确实在乎我的页面加载速度以及它们占用了多少带宽。

尽管我完全同意这是丑陋的标记，但我认为使用丑陋的视图语法将ASP.NET MVC整体注销是不公平的。View语法受到了Microsoft的最少关注，我完全希望很快就可以对此采取一些措施。

其他答案已经讨论了整个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格式加载视图时，该文本将呈现（同样适用于布局人员）

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

mvc：inner =“”-引号中的所有内容都会被评估，并且标记的内部HTML会替换为结果字符串。（我们的示例文本被替换了）

mvc：outer =“”-对引号中的内容进行评估，并用结果字符串替换标记的外部HTML。（再次，示例文本被替换。）

{}-用于在属性内部插入输出，类似于<％=％>

mvc：if =“”-insde qoutes是要被评估的布尔表达式。if的关闭是HTML标记关闭的位置。

mvc：else

mcv：elseif =“”-...

mvc：foreach

现在，我只能在这里为自己说话：

IMO，如果您是顽固的（任何东西），那么转换不适合您。如果您喜欢WebForms，那是因为您可以完成所需的工作，这也是所有工作的目标。

Webforms很好地从开发人员那里提取了HTML 。如果这是您的目标，请坚持使用Web窗体。您拥有所有出色的“单击和拖动”功能，这些功能已使桌面开发变得今天如此。有许多包含的控件（加上大量的第三方控件）可以带来不同的功能。您可以从数据库中拖动与数据源直接关联的“网格”。它带有内置的内联编辑，分页等功能。

到目前为止，ASP.NET MVC在第三方控件方面非常有限。再说一次，如果您喜欢快速应用程序开发，那里为您提供了很多功能，那么您不应该尝试进行转换。

综上所述，这就是ASP.NET的亮点：-TDD。Nuff说，代码不可测试。

• 关注点分离。那就是MVC模式的骨干。我完全知道您可以在Web窗体中完成此操作。但是，我喜欢强加的结构。在Web Forms中，混合设计和逻辑太容易了。ASP.NET MVC使团队的不同成员更轻松地处理应用程序的不同部分。

• 来自其他地方：我的背景是CakePHP和Ruby on Rails。因此，很明显我的偏见在哪里。这只是关于您的舒适程度。

• 学习曲线：扩展到最后一点；我讨厌“模板化”以更改不同元素的功能的想法。我不喜欢许多设计是在文件背后的代码中完成的事实。当我已经非常熟悉HTML和CSS时，这是另一件事。如果要在页面上的“元素”中执行某项操作，请插入“ div”或“ span”，在上面贴上ID，然后退出。在Web窗体中，我将不得不研究如何执行此操作。

• Web“设计”的当前状态：jQuery之类的JavaScript库正变得越来越普遍。Web窗体处理ID的方式只会使实现（在Visual Studio之外）更加困难。

• 更多分离（设计）：由于许多设计都已连接到控件中，因此外部设计师（没有Web窗体）知识很难在Web窗体项目上工作。Web Forms被构建为最终一切。

同样，这些原因中有许多是由于我对Web Forms不熟悉。Web窗体项目（如果设计正确）可以享受ASP.NET MVC的“大部分”好处。但这是警告：“如果设计正确”。那只是我不知道如何在Web窗体中执行的操作。

如果您在Web窗体中进行出色的工作，那么您将有效率并为您工作，这就是您应该坚持的地方。

基本上，对两者都做一个快速回顾（尝试找到一个公正的来源[好运]），并列出一系列利弊，评估哪一个适合您的目标并根据此选择。

最重要的是，选择阻力最小，收益最大的途径来实现您的目标。Web窗体是一个非常成熟的框架，将来只会变得更好。ASP.NET MVC仅仅是另一种选择（使用Ruby on Rails和CakePHP开发人员（例如：我：P））

首次提出Java EE的JSP时，它就是这样-丑陋的scriptlet代码。

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

我认为最好的解决方案是JSP标准标记库（JSTL）。它是HTML的“标准”标记，有助于防止人们将逻辑放入页面中。

另一个好处是，它保留了Web设计人员和开发人员之间的分界线。我看到的好网站是由具有审美意识并为可用性设计的人们设计的。他们布置页面和CSS并将其传递给开发人员，然后由开发人员添加动态数据位。作为缺少这些礼物的开发人员，我认为当我们要求开发人员编写从汤底到坚果的网页时，我们会付出重要的努力。Flex和Silverlight会遇到相同的问题，因为设计人员不太可能会很好地了解JavaScript和AJAX。

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

只是想我将与闪亮的新Razor视图引擎共享该示例的外观，该视图引擎自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很少伤害。这是我的方法：

<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>

我不能直接谈ASP.NET MVC项目，但是一般来说MVC框架已经成为Web应用程序开发的主导者，因为

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

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

最后一点才是重要的。使用Webforms和类似技术，您可以依靠供应商为您编写HTML / CSS / Javascript。它功能强大，但是您不能保证当前版本的Webforms可以与下一代Web浏览器一起使用。

这就是视图的力量。您可以完全控制应用程序的HTML。不利的一面是，您需要受到足够的训练，以将视图中的逻辑保持在最低限度，并使模板代码尽可能地简单。

所以，这就是权衡。如果Webforms适合您，而MVC却不行，请继续使用Webforms

我对它的最大挫败就是不知道如何“正确”地做事。自从它作为预览发布以来，我们所有人都有一点时间来查看事物，但是它们已经发生了很大的变化。起初，我真的很沮丧，但是该框架似乎足够可行，可以使我快速创建极其复杂的UI（阅读：Javascript）。我知道您可以像以前一样使用Webforms来做到这一点，但是在试图使所有内容正确呈现方面，这是一个巨大的痛苦。很多时候，我最终会使用中继器来控制确切的输出，并且最终还会遇到很多上面的意大利面混乱。

为了避免出现混乱，我一直在使用具有域，服务层和dto的组合来传输到视图。将其与spark，视图引擎结合在一起，它会变得非常不错。设置需要一些时间，但是一旦完成，就可以看到我的应用程序在视觉上的复杂性有了很大的提高，但是这样做非常简单，可以明智地执行代码。

我可能不会完全像这样做，但这是您的示例：

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

这很容易维护，可测试，并且在我的代码汤中味道很好。

得出的结论是，干净的代码确实是可能的，但与我们的工作方式相比，这是一个很大的转变。我不认为每个人都对此感到困惑。我知道我还在想办法...

史蒂夫·桑德森（Steve Sanderson）最近出版的Apress书“ 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

我希望看到Phil Haack的帖子，但是这里没有，所以我只是从http://blog.wekeroad.com/blog/i-spose-ill-just-say-say-it-you-should中剪切并粘贴了它 -learn-mvc /在评论部分

哈克（Haacked）-2009年4月23日-罗伯（Rob），你很暴动！:)当人们在MVC中编写意大利面条代码然后说“看！意大利面条！”时，我的确感到很有趣。嘿，我也可以在Web窗体中编写意大利面条代码！我可以用Rails，PHP，Java，Javascript编写它，但是不能用Lisp编写。但这仅仅是因为我还不能用Lisp编写任何东西。而且，当我编写意大利面条代码时，我不会为看到通心粉而沮丧地看着我的盘子。人们将其与经典ASP进行比较时经常指出的一点是，与经典ASP相比，人们倾向于混合考虑。页面将具有视图逻辑，将用户输入处理与模型代码和业务逻辑混合在一起。这就是意大利面的目的！混杂在一起成为一团糟。使用ASP.NET MVC，如果遵循该模式，则不太可能这样做。是的 您的视图中可能仍然有一些代码，但是希望这就是所有视图代码。该模式鼓励您不要在其中放置用户交互代码。将其放入控制器中。将您的模型代码放在模型类中。那里。没有意大利面。现在是O-Toro Sushi。:)

我也是; 我会花时间在Silverlight而不是ASP.NET MVC上。我尝试了MVC 1.0，并在几天前查看了最新的2.0 Beta 1版本。

我（无法）觉得ASP.NET MVC比Webform更好。MVC的卖点是：

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

但是Webform通过使用后台代码，主题，外观和资源已经非常适合将设计和逻辑分开。

Viewstate：客户端ID管理即将在ASP.NET 4.0上进行。我只关心单元测试，但是单元测试不足以使我从Webform转向ASP.NET MVC。

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

自从Preview 3发布以来，我就一直在使用MVC，尽管它仍然有它的成长烦恼，但是它在团队开发领域中起了很大的作用。尝试让三个人在一个Web表单页面上工作，然后您就会明白将头撞在墙上的概念。我可以与一个理解视图页面上的设计元素的开发人员以及我们常驻的Linq神一起工作，以使模型正常工作，同时将所有内容放到控制器中。我从未能够在如此容易实现关注点分离的领域中发展。

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

话虽这么说...您的代码比我通常使用视图页面时的代码漂亮得多。另外，与我一起工作的人之一正在将HTML帮助程序包装到标签库中。而不是<％= Html.RandomFunctionHere（）％>

<hh：randomfunction />

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

使用外观模式包装需要显示的所有数据的所有逻辑，然后将其用作视图中的通用对象，然后....不再需要意大利面条式代码。 http://en.wikipedia.org/wiki/Design_pattern_(computer_science）

如果您需要更多帮助，请联系cgardner2020@gmail.com

ASP.NET MVC的实现是可怕的。产品很烂。我已经看过几个演示了，我为MSFT感到羞愧。 。

我认识的唯一尝试实施MVC的人是喜欢尝试MSFT新事物的人。在我看到的演示中，主持人的语气很抱歉。

我是MSFT的忠实拥护者，但我不得不说，我认为没有理由为他们实施MVC感到烦恼。使用Web窗体或使用jquery进行Web开发，请不要选择可憎的方式。

编辑：

Model-View-Controller体系结构设计模式的目的是将您的域与表示与业务规则分开。我已经在实现的每个Web Forms项目中成功使用了该模式。ASP.NET MVC产品不能很好地适应实际的体系结构设计模式。