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

你可能感兴趣的:(Web框架、MVC和ASP.NET)