Web 框架、MVC 和 ASP.NET

在社区技术预览版发布只后差不多过了一年，微软才第一次发布了真正算得上是试用版的 ASP.NET MVC 框架。ASP.NET MVC 从根本上脱离了过去所提倡的 WebForms 技术，而被普遍认为是向主流 Web 编程的回归。MVC 模式奠定了许多 Web 框架例如 Ruby on Rails 和 Java Spring 框架等的坚实基础。

不应将 MVC Web 框架与同名的 MVC（Model-View-Controller）模式混为一谈。后者最初是由 Trygve Reenskaug 提出来的。在 Reenskaug 提出的模式中，视图与控制器紧密结合，在之间形成了一对一的映射关系。而在 MVC Web 框架中，视图与控制器是松散耦合的，并且，多个视图与单个控制器相结合的情形可谓司空见惯。

不管你更偏爱哪一种 MVC 的定义，模型（Model）仍然是一种独立的数据展现，它并不知道展现的数据会被如何使用。这与 WebForms 截然相反，在 WebForms 中，数据通常会以视图状态的形式存储在 UI 元素中。

微软的 MVC 框架牺牲了窗体和控件的快速开发能力，通过直接控制 HTML 的输出以换取系统的灵活性和准确性。这种理念上的变化可能代表着一种重心的转移，更加偏向于开发经典 ASP 的程序员，或者非微软语言的程序员，而不是已经具有.NET 编程背景的开发人员。

随着第一个ASP.NET 试用版的发布，其中的某些新特性试图在引导开发人员建立新的思维方式。例如，程序员现在可以通过右键单击相关的控制器类或者敲击Ctrl-M Ctrl-V，就可以创建新的视图，同时，还会生成视图所要绑定的模型对象。

另一个背离WebForms 的特性是对JavaScript 的重视。WebForms 试图对开发人员隐藏JavaScript，将它包装在控件中，或者通过在服务端处理数据的方式，而ASP.NET MVC 却接纳了它。通过创建默认的MVC Web 站点就可获得“Scripts”文件夹，这是通过ASP.NET AJAX 和 jQuery 预先生成的。它对 ASP.NET AJAX 提供了完全的智能感应，而对于后者则给与了部分支持。但这只是暂时的，在未来几周内，对 jQuery 完全支持的标记也将面世。

微软总是对数据绑定情有独钟，ASP.NET MVC 也不例外。微软的“Model Binders”允许开发人员快速地将 HTTP POST 的数据映射为对象的属性，然后再将这些对象发送到控制器类的 action 方法。在本次发布的版本中，增加了对通用.NET 类的默认绑定器（binder）。但是切记在大多数情形下，开发人员还是需要创建他们自己的。

Web 站点的自动测试是微软目前提供的另一个主流概念。与其它框架对于测试只提供口头承诺不同，微软从一开始就对其制定了计划。在测试控制器和模型时，不再需要 Mock，重要的是它们包含了所有可测试的逻辑。视图的测试仍然需要在外部执行，包括针对不同的所支持的浏览器对 HTML 的检查。

ASP.NET 的另一个方面是回归对 HTTP 动词的关注。这一项在更早的技术如经典的 ASP 中殊为重要的内容，WebForms 的开发人员几乎忘记了它们的存在。他们并不知道 post-back 会导致 POST 动作，Response.Redirect 会产生 Get 动作，而仅仅会使用它们。在 ASP.NET MVC 中，HTTP 动词极为重要，这从其 API 中就可看出端倪。在通常的任务中，就像限制某些动作只能执行一个特定的动词时，就可以在控制器的方法中，通过 AcceptVerbs 特性中对其进行标注。

为了便于将微软自己的方法替换为开发人员自己编写的方法，所有 HTML 辅助方法都被定义为扩展方法。这样就可以对它们进行部分替换，或者通过简单地改变 using/imports 语句，完成对整个的替换。

对于那些忠实的 WebForms 迷们，微软也不会抛弃他们。Scott Guthrie 写道：

我总是愿意确定无疑地指出：如果你不喜欢 MVC 模型，或者你觉得它与你的开发方式天生相克，你完全可以置之不理。MVC 模型仅仅提供了一个额外的选择，而不是要替换现有的 WebForms 模型。WebForms 和 MVC 都会被鼎力支持，一以贯之（在.NET 4.0 中，ASP.NET WebForms 会添加更为丰富的 URL 路由特性，更好的 HTML CSS 标记的支持，提供完整地具有 ClientId 属性的控件，更多 AJAX 特性，还有更多特性我会很快在博客中广而告之）。如果你不喜欢 MVC，不用担心，千万不要觉得你应该或者必须使用它，完全不必如此。

查看英文原文： Web Frameworks, MVC, and ASP.NET