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