自从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中弄乱了我的缩进，只要我有易于维护的代码......这不是！
所以，转换我，一个顽固的网络形式的家伙，为什么我应该放弃我的格式很好的ASPX页面呢？
编辑：粗体显示“临时Html / css”行，以便人们对此有所了解。
答案 0 :(得分：147)
答案 1 :(得分：117)
MVC让您可以更好地控制输出，使用该控件可能会更有可能编写设计糟糕的HTML，标签汤等......
但与此同时，你有几个你以前没有的新选择......
现在不是说你不能用WebForms做任何这些事情，但是MVC让它更容易。
当我需要快速创建Web应用程序时，我仍然使用WebForms，因为我可以利用服务器控件等.WebForms隐藏了输入标签和提交按钮的所有细节。
如果您不小心，WebForms和MVC都能够绝对垃圾。与往常一样，仔细规划和深思熟虑的设计将产生高质量的应用程序，无论它是MVC还是WebForms。
<强> [更新]
如果还有任何安慰，MVC只是微软新推出的一项技术。有很多帖子表明，WebForms不仅会继续存在，而且会继续为...而开发。
......等等......
对于那些关注MVC正在采取的路线的人，我建议给“伙计们”你的反馈意见。到目前为止他们似乎在听！
答案 2 :(得分：76)
对ASP.NET MVC的大多数反对意见似乎都围绕着视图，这些视图是架构中最“可选”和模块化的位之一。 NVelocity，NHaml，Spark，XSLT和其他视图引擎可以easily swapped out（每次发布都会变得更容易）。其中许多都有更简洁的语法来进行表示逻辑和格式化，同时仍然可以完全控制发出的HTML。
除此之外，几乎每一个批评似乎都归结为＆lt; %%＆gt;在默认视图中标记以及它是多么“丑陋”。这种观点通常植根于WebForms方法，它只是将大多数经典的ASP丑陋转移到代码隐藏文件中。
即使没有代码隐藏“错误”，你也会在Repeater中使用像OnItemDataBound这样的东西，就像一样美学丑陋，如果只是以不同于“标签汤”的方式。 foreach循环可以更容易阅读，即使在该循环的输出中使用变量嵌入，特别是如果您从其他非ASP.NET技术来到MVC。理解foreach循环需要花费更少的Google-fu，而不是弄清楚修改转发器中的那个字段的方法是弄乱OnItemDataBound（以及检查它是否是要更改的正确元素的老鼠的嵌套。
ASP标签 - 汤驱动的“spaghetti”的最大问题更多的是在HTML之间推送数据库连接之类的东西。
碰巧使用＆lt; %%＆gt;这样做了只是与经典ASP的意大利面性质相关，而不是因果关系。如果您将视图逻辑保持为HTML / CSS / Javascript以及执行 presentation 所需的最小逻辑，则其余的是语法。
在将一些功能与WebForms进行比较时，请确保包含所有设计器生成的C＃，以及代码隐藏的C＃和.aspx代码，以确保MVC解决方案实际上不是，实际上，更简单。
当明智地使用部分视图来表示可重复的表示逻辑时，它真的可以很漂亮和优雅。
就个人而言，我希望早期教程内容的大部分内容更多地集中在这些事情的结尾，而不是几乎完全依赖于测试驱动，控制反转等。而其他的东西是专家反对的，那些人在战壕里更有可能反对“标签汤”。
无论如何，这是一个仍处于测试阶段的平台。尽管如此，与大多数Microsoft-beta技术相比，它正在进行更多的部署和非Microsoft开发人员使用它构建实际内容。因此，嗡嗡声往往使它看起来比它周围的基础设施（文档，指导模式等）更进一步。它在这一点上真正可用，只是放大了这种效果。
答案 3 :(得分：59)
<% 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实现对于这个问题会是什么样子。
答案 4 :(得分：25)
我不确定人们在什么时候停止关心他们的代码。
HTML是您工作中最公开的展示，有很多开发人员使用记事本，记事本++和其他纯文本编辑器来构建很多网站。
MVC是关于从Web表单获取控制权，在无状态环境中工作，以及实现模型视图控制器设计模式，而没有通常在此模式的实现中进行的所有额外工作。
如果你想要控制，清理代码和使用MVC设计模式，这对你来说，如果你不喜欢使用标记，不关心你的标记有多么错误，那么使用ASP.Net Web形式。
如果您不喜欢，那么您肯定会在标记中做同样多的工作。
修改 我还应该声明Web Forms和MVC有它们的位置，我并没有说明一个比另一个好，只是每个MVC都有重新控制标记的力量。
答案 5 :(得分：15)
我认为你错过了一些东西。首先，不需要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>
<% } %>
答案 6 :(得分：14)
与MVC的关键在于它是一个已经存在很长时间的概念框架，它已经证明自己是一种高效，强大的方式来构建水平和垂直扩展的Web应用程序和工作站应用程序。它直接回到Alto和Smalltalk。微软迟到了。我们现在使用ASP.NET MVC的原因是非常原始的，因为有很多事情要做;但该死的，他们正在快速而疯狂地推出新版本。
Ruby on Rails有什么大不了的？ Rails是MVC。开发人员一直在转换，因为通过口口相传，它成为程序员提高工作效率的途径。
这是一笔巨大的交易; MVC和jQuery的隐含认可是微软接受平台中立至关重要的转折点。对于它来说，中立的是，与Web Forms不同，Microsoft无法在概念上锁定您。您可以完全使用所有C＃代码并重新实现另一种语言（比如PHP或java - 您可以命名），因为它是可移植的MVC概念，而不是代码本身。 （并且认为你可以采用你的设计并将其作为工作站应用实现，只需很少的代码更改，并且不需要进行任何设计更改。请尝试使用Web窗体。）
Microsoft决定Web Forms不会成为下一个VB6。
答案 7 :(得分：14)
请查看Rob Conery的帖子I Spose I’ll Just Say It: You Should Learn MVC
答案 8 :(得分：9)
ASP.NET MVC框架相对于Web表单的两个主要优点是：
现在，这些原因并没有真正使ASP.NET MVC以黑白方式比Web表单更好或更差。 ASP.NET MVC有其优点和缺点，就像Web表单一样。然而，大多数关于ASP.NET MVC的抱怨似乎源于对如何使用它而不是框架中的实际缺陷缺乏了解。您的代码感觉不正确或外观正确的原因可能是因为您拥有多年的Web表单经验，并且只有1-2个月的ASP.NET MVC经验。
这里的问题不在于ASP.NET MVC晃动或糟透了，它是新的，并且关于如何正确使用它的协议很少。 ASP.NET MVC对应用程序中发生的事情提供了更细粒度的控制。这可以使某些任务更容易或更难，具体取决于您如何处理它们。
答案 9 :(得分：8)
就在最近，我花了两天时间试图找出在MVC中向“网格”添加分页的最佳方法。现在，通过webforms，我可以立刻将其甩掉。但我会说这个...一旦我有为MVC构建的分页助手类，它实现起来变得非常简单。对我而言，比webforms更容易。
话虽如此，我认为当有一套一致的HTML Helpers时，MVC将更加适合开发人员。我想我们将在不久的将来开始在网络上看到大量的HTML帮助程序类。
答案 10 :(得分：8)
这很有趣，因为这就是我第一次看到网络表格时所说的内容。
答案 11 :(得分：6)
我承认我还没有获得asp.net MVC。我正试图在我正在做的一个侧面项目中使用它，但它的速度很慢。
除了无法在网络表单中做那些容易做的事情之外，我还注意到标签汤。从这个角度看，它似乎确实倒退了一步。我一直希望，随着我的学习，它会变得更好。
到目前为止，我已经注意到使用MVC的主要原因是要完全控制HTML。我还读到asp.net MVC能够比Web表单更快地提供更多页面，并且可能与此相关，单个页面大小小于普通Web表单页面。
我真的不在乎我的HTML看起来像什么，只要它在主流浏览器中工作，但我确实关心我的页面加载速度和占用的带宽。
答案 12 :(得分：6)
虽然我完全同意这是丑陋的标记，但我认为使用丑陋的视图语法来整理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;" />
这有几个好处：
那么，这种语法到底是做什么的？
mvc：inner =“” - 引号中的任何内容都会被评估，并且标记的内部HTML将替换为结果字符串。 （我们的示例文本被替换）
mvc：outer =“” - 引号中的任何内容都会被评估，并且标记的外部HTML将替换为结果字符串。 （再次，示例文本被替换。）
{} - 用于在属性中插入输出，类似于＆lt;％=％＆gt;
mvc：if =“” - insde qoutes是要被评估的布尔表达式。 if的关闭是HTML标记关闭的位置。
MVC：其他
mcv：elseif =“” - ...
MVC：的foreach
答案 13 :(得分：4)
现在，我只能在这里说话：
IMO，如果你是一个顽固的（任何事情）那么转换不适合你。如果你喜欢WebForms，那是因为你可以完成你需要的东西，这也是你的目标。
Webforms在从开发人员中抽象HTML方面做得很好。如果这是您的目标，请坚持使用Web窗体。您拥有所有精彩的“点击和拖动”功能，使桌面开发成为今天的样子。有许多控件（加上大量第三方控件）可以带来不同的功能。您可以从数据库中拖动与数据源直接关联的“网格”;它带有内置的内联编辑，分页等。
截至目前，ASP.NET MVC在第三方控件方面非常有限。再说一次，如果你喜欢快速应用程序开发，那里有很多功能，你就不应该尝试转换。
所有这些都说，这是ASP.NET闪耀的地方： - TDD。代码是不可测试的，nuff说。
分离关注点。这是MVC模式的支柱。我完全知道您可以在Web窗体中完成此操作。但是，我喜欢强制结构。在Web窗体中混合设计和逻辑太容易了。 ASP.NET MVC使团队的不同成员可以更轻松地处理应用程序的不同部分。
来自其他地方：我的背景是CakePHP和Ruby on Rails。所以，很明显我的偏见所在。这只是关于你感到满意的事情。
学习曲线：扩展最后一点;我讨厌“模板化”改变不同元素功能的想法。我不喜欢在代码隐藏文件中完成了很多设计的事实。当我已经非常熟悉HTML和CSS时，还有一件事需要学习。如果我想在页面上的“元素”中执行某些操作，我会粘贴在“div”或“span”中，在其上打一个ID然后关闭。在Web窗体中，我必须研究如何做到这一点。
Web“设计”的当前状态：像jQuery这样的Javascript库变得越来越普遍。 Web窗体破坏ID的方式只会使实现（在Visual Studio之外）变得更加困难。
更多分离（设计）：由于很多设计都连接到您的控件中，因此外部设计人员（没有Web窗体）知识在Web窗体项目上工作将非常困难。 Web表单的构建是最终的结果。
同样，其中很多原因源于我对Web表单的不熟悉。 Web窗体项目（如果设计正确）可以具有ASP.NET MVC的“最大”好处。但这是警告：“如果设计正确”。而这只是我不知道如何在Web窗体中做的事情。
如果您在Web窗体中做出了出色的工作，那么您就是高效的，它对您有用，那就是您应该留下的地方。
基本上，快速审查两者（尝试找到一个无偏见的来源[祝你好运]），列出一个优点和缺点，评估哪一个适合你的目标，并根据这一点进行选择。
最重要的是，选择阻力最小的路径，最有利于实现目标。 Web Forms是一个非常成熟的框架，将来只会变得更好。 ASP.NET MVC只是另一种选择（用Ruby on Rails和CakePHP开发人员绘制，比如我自己：P）
答案 14 :(得分：3)
以为我会分享这个示例如何看待自ASP .NET MVC 3以来默认的闪亮的新Razor view engine。
@{
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>
答案 15 :(得分：3)
Java EE的JSP在首次提出时看起来像这样 - 丑陋的scriptlet代码。
然后他们提供了标签库，使它们更像HTML标签。问题是任何人都可以编写标签库。一些结果是灾难性的，因为人们将大量逻辑（甚至样式）嵌入到生成HTML的标记库中。
我认为最好的解决方案是JSP标准标记库（JSTL）。它是“标准”，HTML标签，并有助于防止人们将逻辑放入页面。
另一个好处是它保留了网页设计师和开发人员之间的界限。我看到的好网站是由具有审美感和可用性设计的人设计的。他们布置页面和CSS并将它们传递给开发人员，后者添加了动态数据位。作为一个缺乏这些礼物的开发人员，我认为当我们要求开发人员从汤到坚果编写网页时，我们会给出一些重要信息。 Flex和Silverlight会遇到同样的问题，因为设计人员不太可能很好地了解JavaScript和AJAX。
如果.NET有一条类似于JSTL的路径，我建议他们调查它。
答案 16 :(得分：2)
我不能直接与ASP.NET MVC项目对话，但一般来说MVC框架已经成为 web 应用程序开发的主导因为
它们提供了数据库操作，“业务逻辑”和演示文稿之间的正式分离
他们在视图中提供足够的灵活性，允许开发人员调整他们的HTML / CSS / Javascript以在多个浏览器中工作，以及这些浏览器的未来版本
这是最重要的一点。使用Webforms和类似技术，您依靠供应商为您编写HTML / CSS / Javascript。它是功能强大的东西，但您无法保证当前版本的Webforms将与下一代Web浏览器一起使用。
这就是观点的力量。您可以完全控制应用程序的HTML。缺点是，你需要足够严格，以便将视图中的逻辑保持在最低限度，并尽可能简化模板代码。
所以，这是权衡。如果Webforms为您工作而MVC不工作，那么继续使用Webforms
答案 17 :(得分：2)
我对它的挫败感大部分都是不知道如何“正确”地做事。自从它作为预览发布以来，我们都有一些时间来看待事物，但它们已经发生了很大变化。起初我真的很沮丧，但框架似乎足够可行，使我能够很快创建极其复杂的UI（阅读：Javascript）。我知道你可以像以前那样使用Webforms来做这件事，但是在试图让所有内容正确渲染时，这是一个巨大的痛苦。很多时候我最终会使用转发器来控制确切的输出，最终会出现很多你上面的意大利面。
为了避免同样的混乱，我一直在使用域，服务层和dto的组合来传输到视图。把它与spark，一个视图引擎放在一起，它变得非常好。它需要一些设置，但是一旦你开始，我已经看到了我的应用程序的复杂性在视觉上的一个很大的进步，但它很容易做代码明智。
我不太可能这样做，但这是你的榜样：
<if condition="myDtp.ShowPager">
<div>
<first />
<last />
<div style="clear: both;" />
</div>
</if>
这在我的代码汤中非常易于维护，可测试且味道好。
最重要的是，干净的代码确实是可能的，但这是我们做事的方式的重大转变。我不认为每个人都会这么做。我知道我还在搞清楚......
答案 18 :(得分：2)
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/
答案 19 :(得分：1)
我（不）觉得ASP.NET MVC比webform更好。 MVC的卖点是：
但是webform，通过使用代码隐藏.Theme，Skin和Resource已经完美地分离了设计和逻辑。
Viewstate：客户端ID管理即将推出ASP.NET 4.0。我只关心单元测试，但单元测试不足以成为我从webform转向ASP.NET MVC的理由。
也许我可以说：ASP.NET MVC并不坏，但webform已经足够了。
答案 20 :(得分：1)
我希望看到Phil Haack的帖子，但它不在这里所以我只是剪切并粘贴它 评论部分中的http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should-learn-mvc/
Haacked - 2009年4月23日 - Rob，你是个骚乱！ :)当人们在MVC中写意大利面条代码然后说“看！意大利面！”时，我觉得很有趣。嘿，我也可以在Web Forms中编写意大利面条代码！我可以用rails，PHP，Java，Javascript编写它，但不能用Lisp编写。但这只是因为我还没有在Lisp中写任何东西。当我写意大利面条代码时，我不会看到我的盘子闷闷不乐地期待看到通心粉。人们在将其与传统ASP进行比较时经常提出的一点是，对于传统的ASP，人们往往会混淆顾虑。页面将具有视图逻辑，其中用户输入处理与模型代码和业务逻辑混合在一起。这就是意大利面条的意思！混合关注所有的混乱。使用ASP.NET MVC，如果您遵循该模式，则不太可能这样做。是的，你的视图中仍然可能有一些代码，但希望这是所有视图代码。该模式鼓励您不要将用户交互代码放在那里。把它放在控制器中。将模型代码放在模型类中。那里。没有意大利面。现在是O-Toro寿司。 ：）
答案 21 :(得分：-1)
我一直在使用MVC，因为预览版3出现了，虽然它仍然有它成长的痛苦，它在团队开发领域有很大的帮助。尝试让三个人在一个webforms页面上工作，然后你就会明白把头撞在墙上的概念。我可以与一个了解视图页面上的设计元素的开发人员和我们的常驻Linq上帝一起工作，同时将所有内容放在控制器中。我从来没有能够在一个容易分离问题的领域中发展。
ASP.Net MVC的最大卖点 - StackOverflow runs on the MVC stack.
话虽如此......你的代码比我通常对视图页面做的更漂亮。此外，我与之合作的其中一个人正致力于将HTML帮助程序包装到标记库中。而不是＆lt;％= Html.RandomFunctionHere（）％＆gt;它就像
一样＆LT; hh：randomfunction /＆gt;
我只是希望MVC团队在某些时候能够解决这个问题，因为我相信他们会做得更好。
答案 22 :(得分：-2)
使用Facade Pattern包装您需要显示的所有数据的所有逻辑，然后在视图中将其用作通用，然后......不再使用意大利面条代码。 http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
如果您需要更多帮助cgardner2020@gmail.com
答案 23 :(得分：-18)
ASP.NET MVC的实现非常糟糕。产品简直糟透了。我已经看过它的几个演示而且我对MSFT感到羞耻......我确信编写它的人比我聪明，但它几乎就像他们不知道模型 - 视图 - 控制器是什么。
我认识的唯一尝试实施MVC的人是喜欢尝试MSFT新事物的人。在我看过的演示中，演示者有一种抱歉的语气......
我是MSFT的忠实粉丝，但我不得不说我没有理由去理解它们的MVC实现。无论是使用Web窗体还是使用jquery进行Web开发，都不要选择这种可憎的行为。
修改
模型 - 视图 - 控制器架构设计模式的目的是将您的域与演示文稿与业务规则分开。我已经在我实现的每个Web窗体项目中成功使用了该模式。 ASP.NET MVC产品不适合实际的架构设计模式。