当我第一次听说StackOverflow并听说它是在ASP.Net MVC中构建时，我有些困惑。我以为ASP.Net始终是MVC架构的一个示例。我们具有提供视图的.aspx页面，提供控制器的.aspx.vb页面，并且我们可以创建另一个类作为模型。 Microsoft文章中介绍了在ASP.Net中使用MVC的过程。

所以我的问题是。 ASP.Net MVC有什么功能，使我们无法使用常规ASP.Net(甚至可以追溯到ASP.Net 1.1)？只是花哨的网址？仅仅是为了让MS能够与Ruby On Rails等新技术进行比较，并宣称自己"我们也可以做到"，是为了吹牛呢？还有ASP.Net MVC实际提供的更多功能，而不是File-> New菜单中的几个额外模板？

我现在可能听起来真的很怀疑并且很消极，所以我就停下来。但是我真的很想知道ASP.Net MVC实际提供了什么。另外，如果有人可以告诉我为什么是Model-View-Controller，而不是按照View-Controller-Model或者Model-Control-View的层级顺序排列，这取决于我们是自上而下还是相反？也真的很感激。

编辑

另外，可能值得指出的是，我也从未真正关心过Web表单(AKA服务器控件)模型。我只用了很少的东西，从没做过。

解决方案

带有代码的ASP.Net几乎是MVC，但没有什么大不了的是，其背后的代码直接与aspx关联，后者是MVC的重要组成部分。如果我们将后台代码视为控制器，则应将其与视图完全分离。新的.NET MVC对此进行了完善，并带来了一个完整的MVC框架。尽管已经有.NET的现有版本(请参阅Spring.NET)。

.aspx无法实现MVC模式，因为aspx页("视图")在其后面的代码("控制器")之前被调用。

这意味着控制器对视图具有"硬依赖性"，这在很大程度上违反了MVC原则。

MVC的核心优势之一是它允许我们在不实例化真实视图的情况下测试控制器(包含很多逻辑)。在.aspx世界中，我们根本无法做到这一点。

与必须实例化整个asp.net管道(应用程序，请求，响应，视图状态，会话状态等)相比，单独测试控制器要快得多。

首先，它使创建具有明确职责分工的可测试网站变得非常容易。使用新的MVC框架创建有效的XHTML UI也更加容易。

我已经使用第二个CTP(我认为他们现在已经是五个)开始在网站上工作，并且之前已经创建了一些Web应用程序，我不得不说它比使用服务器控制模型好数百倍。

如果我们不知道自己在做什么，则可以使用服务器控件。当我们开始了解Web应用程序应如何工作时，便开始与之抗争。最终，我们必须编写自己的代码才能克服当前控件的缺点。在这一点上，MVC开始大放异彩。而且这甚至都没有考虑到我们网站的可测试性...

Dino Esposito的精彩文章旨在向ASP.net Webforms开发人员解释ASP.net MVC：

http://dotnetslackers.com/articles/aspnet/AnArchitecturalViewOfTheASPNETMVCFramework.aspx

我看了几个简单的例子，例如这个例子。我可以看到区别。但是，我真的看不到MVC如何将视图与控制器解耦。该视图仍引用控制器中的内容。我确实看到它如何使它更容易测试，并且至少在MVC中，控制器对视图不了解。而且，我们不必处理视图即可调用控制器中的方法。我可以看到这是一个飞跃，尽管乍一看似乎并不多。

我确实同意@Will关于应对服务器控件的问题。我从来没有在实际使用过的情况下工作过，但是我认识的许多人在使用它们时遇到了很多限制。

不再需要自动生成的HTML ID ！！！任何使用任何javascript的人都赞赏这一事实。

关于ASP.net MVC与ASP.net Web表单的文章

http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx

Scott Guthrie在本文" ASP.NET MVC框架"中对此进行了解释。

It enables clean separation of concerns, testability, and TDD by
  default.  All core contracts within
  the MVC framework are interface based
  and easily mockable (it includes
  interface based
  IHttpRequest/IHttpResponse
  intrinsics).  You can unit test the
  application without having to run the
  Controllers within an ASP.NET process
  (making unit testing fast).  You can
  use any unit testing framework you
  want to-do this testing (including
  NUnit, MBUnit, MS Test, etc).
  It is highly extensible and pluggable.  Everything in the MVC
  framework is designed so that it can
  be easily replaced/customized (for
  example: you can optionally plug-in
  your own view engine, routing policy,
  parameter serialization, etc).  It
  also supports using existing
  dependency injection and IOC container
  models (Windsor, Spring.Net,
  NHibernate, etc).
  It includes a very powerful URL mapping component that enables you to
  build applications with clean URLs. 
  URLs do not need to have extensions
  within them, and are designed to
  easily support SEO and REST-friendly
  naming patterns.  For example, I could
  easily map the /products/edit/4 URL to
  the "Edit" action of the
  ProductsController class in my project
  above, or map the
  /Blogs/scottgu/10-10-2007/SomeTopic/
  URL to a "DisplayPost" action of a
  BlogEngineController class.
  The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and
  .Master markup files as "view
  templates" (meaning you can easily use
  existing ASP.NET features like nested
  master pages, <%= %> snippets,
  declarative server controls,
  templates, data-binding, localization,
  etc).  It does not, however, use the
  existing post-back model for
  interactions back to the server. 
  Instead, you'll route all end-user
  interactions to a Controller class
  instead - which helps ensure clean
  separation of concerns and testability
  (it also means no viewstate or page
  lifecycle with MVC based views).
  The ASP.NET MVC framework fully supports existing ASP.NET features
  like forms/windows authentication, URL
  authorization, membership/roles,
  output and data caching,
  session/profile state management,
  health monitoring, configuration
  system, the provider architecture,
  etc.