ASP.NET MVC3简介
2011年10月22日
12:49
对于使用微软平台的开发人员来说，ASP.NET MVC框架有了一个根本的转变.它强调"干净的"体系、设计模式、可测试性，同时它并不尝试隐藏WEB的工作细节。
本书第一部分介绍ASP.NET MVC框架的基本理念，包括ASP.NET MVC3的新功能,同时亲身体会这个框架的易用性.
第一章 What's the Big Idea?(暂时译为:最好的选择是什么?)
2011年10月22日
13:01
ASP.NET MVC是微软公司出品的WEB开发平台,它主要整合了模型-视图-控制器(MVC)体系的高效和简洁、敏捷开发的最新技术和现有ASP.NET平台的最实用的部分。它是传统的ASP.NET WEB窗体模式的完整的替代品，几乎对于所有琐碎的WEB开发项目都有巨大的优势。本章中，我们将会了解到微软为什么会创造出ASP.NET MVC，相比它的前辈和替代品有什么特点，最后，我们将会了解到ASP.NET MVC3增加了哪些新功能。
一 WEB开发平台发展历史简介
要理解ASP.NET MVC的独特性和设计目标，我们需要综合考虑到目前为止WEB开发平台的发展历史（可能比较简单）。近年来，微软的WEB开发平台功能日益强大，但它的复杂度也与日俱增。表1－1显示了微软WEB开发平台的发展路线，每个新平台的出现都是为了解决前一个平台的特定的不足。
|
时期 |
技术 |
优点 |
不足 |
|
侏罗纪 |
通用网关接口（CGI）CGI是一个Web服务器连接到任意一个可执行程序，动态内容返回的标准。该规范是由国家超级计算机中心（NCSA）的中心维护。 |
简单 灵活 当时的惟一选择 |
运行在WEB服务之外，所以它是资源密集的（每个请求产生一个单独的操作系统进程） 低级 |
|
青铜纪 |
Internet数据库连接器 |
运行在WEB服务之内 |
只是一个SQL查询和模板返回集的包装 |
|
1996年 |
动态服务器网页 |
非常通用 |
运行时编译 鼓励“意大利面条式代码” |
|
2002/03 |
ASP.NET Web Forms1.0/1.1 |
已编译 “带状态的”UI界面 巨型的基础架构 鼓励面向对象编程 |
沉重的带宽压力 丑陋的HTML代码生成 不支持自动测试 |
|
2005 |
ASP.NET Web Forms2.0 |
|
|
|
2007 |
ASP.NET AJAX |
|
|
|
2008 |
ASP.NET Web Forms 3.5 |
|
|
|
2009 |
ASP.NET MVC 1.0 |
|
|
|
2010 |
ASP.NET MVC 2.0 ASP.NET Web Forms 4.0 |
|
|
|
2011 |
ASP.NET MVC 3.0 |
|
|
表1－1 微软WEB开发技术家庭表
（一）传统的ASP.NET Web Forms
ASP.NET2002年第一次出现时被为巨大的改变。图1－1显示了微软的技术层次，本章的后面我将会简要介绍这些技术。
图1－1 ASP.NET Web Forms技术体系
微软本意想通过Web Forms技术的推出，将HTTP（其本身固有的无状态性）和HTML（在当时对于许多开发者来说并不太熟悉）的技术细节隐藏，代之以一系列的服务器端控件作为用户界面。每个控件都在用户的请求中保持自已的状态（使用视图状态很容易实现），在需要时将自己重写为HTML标签，自动地将客户端事件（比如单击一个按钮）和相应的服务器端事件处理代码关联起来。实际上，Web Forms本质是一个巨大的抽象层，旨在为Web提供一个典型的事件驱动的图形用户界面（GUI）。
微软想让web开发者感觉到使用Web Forms像使用Windows Forms开发一样。开发者不再需要直接处理一系列相互无关的HTML请求和响应；现在可以把这些想像为状态化的用户界面。我们可以不必在意Web和它固有的无状态性，改为使用一个拖放设计器创建全部的用户界面，然后想像－至少要假设－所有的事件都会在服务端发生。
（二）ASP.NET Web Forms有哪些不足？
传统的ASP.NET Web Forms是一个非常好的主意，但现实需求非常复杂。随着时间的推移，现实世界的项目暴露出Web Forms的一些不足之处：
“沉重的”视图状态：现实中在http请求之间维持状态（术语叫视图状态）导致了服务端和客户端巨大的数据块来回传递。典型情况下这个数据块会大到数百K字节，而且这个数据块会在每次请求时来回传输，导致网站访问者访问速度下降，同时增加了服务器的带宽负担。
页面生存周期：作为页面生存周期的一部分，连接客户端事件和服务端事件处理代码的机制，有时会非常复杂和微妙。很少有开发者能够在运行时成功操纵控件的层次结构而不发生视图状态错误，有时还会发现一些事件处理代码在运行神秘的失败了。
对HTML控制有限：服务端控件在客户端将自身转化为HTML标记，但往往并不是你想要的。在ASP.NET 4.0以前版本中，它的HTML输出通常并不符合WEB标准，和层叠样式表（CSS）也没有良好的结合，而且服务端控件自动创建不可预知的、复杂的标记ID值，导致Javascript难以访问。这些问题在在ASP.NET 4.0里有所改善，但要获取你期望的HTML标记可能依然比较棘手。
有问题的抽象：Web Forms试图尽可能隐藏HTML和HTTP的实现细节。当你想要实现自定义的行为时，你必须频繁地从这种抽象里跳出来，强制你对回发事件机制实施进行逆向工程，采取一些繁琐的方法(obtuse acts)生成你想要的HTML文本。这些抽象甚至会令极富经验的WEB开发者感到令人沮丧的挫折。
低级的可测试性：ASP.NET的设计者压根没有把自动测试作为这个软件开发平台的必要工具。这并不奇怪，他们设计的紧密耦合的体系结构根本不合适进行单元测试，集成测试也是个问题。
ASP.NET在不断发展。2.0版增加了一套标准应用程序组件集，可以减少你需要自己输入的代码量。2007年发布的AJAX版本是微软对当时Web 2.0/AJAX疯狂流行的响应，它支持富客户端交互。最近发布的ASP.NET 4.0版，可以产生大部分可以预见的符合标准的HTML标记，但许多其固有的局限性依然存在。
二 当前流行的WEB开发技术
自微软发布Web Forms以来，web开发技术在几个不同的方向都在快速发展。除了AJAX之外，还有几个重要的发展。
（一）WEB标准化和概念准则（REST）
Web标准化的呼声在近年来不断增多。现在的WEB站点拥有强悍的硬件设备，浏览量也在与日俱增，Web标准化（HTML，CSS，JavaScript等等）可以让我们期望随时随地享受良好的浏览体验－甚至在具备上网功能的冰箱上也一样。现在的Web平台肯定不能忽视商业案例需求和开发者对Web标准化的迫切期望。
与此同时，概念准则（REST）已经成为基于HTTP的应用程序交互的主流架构，完全盖过了SOAP（与ASP.NET中web服务技术类似）。概念准则（REST）从资源角度来描述应用程序，资源（URI）代表真实世界的实体，标准操作（HTTP方法）代表这些资源上有效的操作。例如，你可以提交一个新的类似http://www.example.com/Products/Lawnmower的URI或者删除http://www.example.com/Customers/Arnold-Smith。
当今的Web应用程序不单单只是HTML，通常它们也必须把JSON或XML数据提供给各种客户端技术，包括AJAX、Silverlight，以及本地智能手机应用程序。REST的产生自然而然的消除了web服务和web应用程序的历史差异－但这需要一种对HTTP和URL进行相同处理的办法，而这个在ASP.NET Web Forms上难以得到支持。
（二）敏捷开发和测试驱动开发
过去的十年中，不只是web开发技术在不断发展－软件开发技术作为一个整体已经朝着敏捷开发的方法论方向转变。这么说可能意味着许多不同的事情，但敏捷开发主要是指以循序渐近的方式运作软件开发项目，抵制过分的前瞻性规划造成的妨碍和限制。敏捷开发方法论的关注点倾向于将一整套特定的开发业务和对这些业务有促进和帮助的工具（通常是开源的）紧密结合起来。
测试驱动开发（TDD），以及其最新的变种：行为驱动开发（BDD），就是敏捷开发技术最显著的两个模式。它的理念就是首先通过定义系统的行为（称为测试或规范）来设计你的软件，这样在任何时候，你都可以通过一套定义的系统行为规范对照你的实现来验证你的软件的稳定性和正确性。.NET有很多支持TDD/BDD的工具，但这些工具在Web Forms中使用不是很合适：
单元测试工具使你能测试指定的独立类或者其它孤立的小型代码单元的行为。只有在被设计为一整套独立的模块集组成的软件上才能应用单元测试，因为只有这样每个测试才能独立的运行。不幸的是，几乎没有Web Forms应用程序能够采用这个方式进行测试。
Web Forms的框架要求我们在事件处理函数中放置逻辑处理代码，甚至我们会使用服务端控件直接查询数据库，开发者通常最终将自己的应用程序逻辑和Web Forms运行时环境紧密耦合起来了。这必然使单元测试没戏了。
UI自动化工具允许你按照你的应用程序的完整的运行实例模拟一系列的用户交互。理论上说，在Web Forms中这些都是可行的，但每当你对页面布局进行一次轻微的调整都可能导致这些模拟崩溃。如果不特别指定，Web Forms可能会生成和以往完全不同的HTML结构和元素ID，使得你现有的测试集失去作用。
.NET开源社区和独立软件开发商已经出品了无数的高品质的单元测试框架（如NUnit和xUnit)，模拟框架（如Moq和Rhino Mocks），控制反转容器（如Ninject和AutoFac），持续集成服务器（如Cruise Control和TeamCity），对象关系映射工具（如NHibernate和Subsonic），诸如此类种种。这些工具和技术的支持者们形成了一个团体，他们共同以ALT.NET的名义发表意见和组织会议。传统的ASP.NET Form由于其整体性的设计不适用这些工具和技术，所以在这个由专家和行业精英组成的群体眼里，Web Form无足轻重。
（二） Ruby on Rails项目
2004年Ruby on Rails项目还只是一个由匿名人士资助的默默无闻的开源项目。突然之间就闻名世界，引领web开发技术的潮流。Ruby on Rails并没有包含什么革命性的技术，但它把现有的许多成熟的技术以一种富有吸引力和感染力的方式成功揉合到了一起，一下子就让现有的开发平台处境尴尬。
Ruby on Rails（或者只叫Rails，通常都是这么叫的）包含了一个MVC框架结构。通过应用MVC并使其与HTTP协议和谐相处（而不是反对它），贯彻约定优于配置原则，核心整合对象关系映射工具（ORM），Rails应用程序几乎没有费什么力气就多多少少在开发领域占有了一席之地。好像Web开发一直以来就应该是这样子的；好像我们突然意识到这些年来一直在和开发工具打仗，而现在战争结束了（Rails一统江湖）。
Rails的成功表明遵守Web标准和实施概念准则（REST）不是很困难，同样它也表明在得到框架支持的时候，敏捷开发和测试驱动开发（TDD）的工作效益会非常高。自此，web开发领域出现了百花齐放的景象。
（三） Sinatra－一个微型WEB框架（基于Ruby）
随着Rails的流行，很快就有众多的Web开发人员将Ruby作为自己的主要开发语言。但在我们这样技术密集型的创新社会中，它的替代品的出现只是时间问题。其中最著名的就是2007年出现的Sinatra。
Sinatra基本摒弃了几乎所有的标准的Rails风格的构件（如路由，控制器，视图等等），只是将URL模式映射到Ruby代码块。浏览者请求一个URL，引起Ruby代码块运行，向浏览器返回请求的数据－这就是Sinatra的全部工作。在众多的Web开发技术中它显得极其简陋，但基于以下两个原因，它最终还是找到了自己的位置。首先，对于那些基于概念准则（RESTful）构建的web服务，Sinatra只会让活干得更快（我们将在第14章接触到REST）；其次，由于Sinatra可以连接到广泛的HTML开源项目和ORM技术，它经常被用来作为搭建一个定制的Web框架的基础，以配合我们手上无论哪一种项目的构造需要。
Sinatra并没有像Rails（或者ASP.NET MVC)那样在一系列的MVC开发平台中占据主要地位。我在这里提到它只是为了说明web开发行业正朝着简单化的趋势前进，还因为Sinatra是对抗积聚了越来越多的、越来越复杂的核心功能的其它框架的代表性技术。
（四） Node.js
Web开发的另一个发展趋势就是JavaScript日益成为关键的网络程序设计语言。首先AJAX显示了JavaScript的重要性；然后JQuery告诉我们JavaScript是十分强大和优雅的；最后谷歌的开源项目V8 JavaScript引擎向我们显示了JavaScript可以运行得令人难以置信的快。所有的这些都说明在今天，JavaScript已经成为一个正规的服务端编程语言。它可以为若干非关系型数据库的数据存储和查询语言提供服务，这方面成熟的项目包括CouchDB和Mongo，同时它也可以作为一种服务端平台的通用语言，就比如Node.js。
自2009年起Node.js广泛流行并好评如潮。从结构上看，它类似于Sinatra，它同样也没有应用MVC模式。它以一种更底层的方式将HTTP请求和你的代码连接起来。其主要的创新点有两个：
使用JavaScript:开发者只需要使用单一语言进行工作，从客户端代码，到服务端逻辑，甚至通过类似于CouchDB这样的工具部署数据查询逻辑。
彻底的异步性：当一个线程需要等待输入/输出（I/O）或者其它操作的结果时，Node.js中的API不会以任何方式阻塞这个线程。所有的I/O操作会立即开始动作，在I/O操作完成后线程会接收到回调命令。这就意味着，Node.js使用系统资源的效率极高，单CPU就可以处理数以万计的并发请求（其它平台往往只能处理100个并发请求）。
和Sinatra一样，Node.js是一个非常实用的技术。大部分现实的商业应用都对响应时间有着严格的限定，所以急切需要将一套包含所有上面所说的基础构件的全栈式框架，就像Ruby on Rails和ASP.NET MVC。这里介绍Node.js只是为了说明ASP.NET MVC的设计背景符合行业的发展趋势。比如，ASP.NET MVC中就包含有异步控制器(asynchronous controller)(在第十四章我们会详细说明)。这是一种以非阻塞方式处理HTTP请求的方法，这样可以使每个CPU能够处理更多的请求。你会了解到，ASP.NET MVC和运行在浏览器中的复杂的JavaScript代码结合得非常好。(这些内容会在第18,19.20介绍)。
三 ASP.NET MVC的主要优势
ASP.NET在商业上取得了巨大成功，但正如前所述，其它的WEB开发平台也在不断向前发展。尽管微软一直在努力把緾绕在WEB Forms上的“蜘蛛网”清除掉，但其内在的设计理念已经落伍了。
2007年10月份，在美国德克萨斯州奥斯丁市召开的第一届ALT.NET会议上，微软公司副总裁Scott Guthrie发布并演示了一个基于ASP.NET的崭新的MVC WEB开发平台，明确的被设计为针对类似Rails这样的技术的直接响应，也是对业界关于Web Forms的批评的回应。本章的余下部分描述这个新的平台如何解决Web Forms的种种不足，并令ASP.NET重返顶峰。
(一) MVC体系结构
把MVC构建模式和ASP.NET MVC框架之间的区别搞清楚是十分重要的。MVC模式并不是新生事物－这要追溯到1978年施乐公司帕洛阿尔托研究中心的Smalltalk项目－之所以在今天的WEB开发领域广受欢迎，有以下原因：
MVC应用程序的用户交互符合自然周期：用户执行一个动作，作为响应，应用程序改变它的数据模型，并向用户提供一个更新了的视图。应用程序就一直这样循环的运行。这种模式非常适合WEB应用程序传递
一连串的HTTP请求和响应。
WEB应用程序必然要涉及若干不同的技术领域（数据库，HTML，可执行代码），通常这些技术都分布在不同层面。而MVC的概念很自然的就和这些技术的组合模式对应起来了。
ASP.NET MVC框架实现了MVC模式，而且这样做，有利于更好分离关注。实际上，ASP.NET MVC实现了一个特别为WEB应用开发定制的MVC模式。在第4章你将会了解这个体系的更多的理论，并亲身体验。
通过包含和改进MVC模式，ASP.NET MVC框架相对于Ruby on Rails这样的框架具备了强大的竞争力，同时也将MVC模式引入到主流的.NET领域。通过使用其它平台的开发者提供的对ASP.NET MVC的体验评估和实际应用中反馈，ASP.NET MVC在许多方面甚至已经超越了Rails。
（二） 可扩展性
你的桌面型电脑都是由一些相互独立的部分组成，它们之间通过标准的公开的文档化的接口相互联系。你可以很轻松的把你的显卡和硬盘换成另一个制造商生产的产品，并确信它们可以插进相应的槽位并正常工作。MVC框架的原理和PC一样也是构建在一系列相互独立的组件的基础之上－如一个可信的.NET接口或继承抽象基类的用户类－这样你就可以轻而易举的用你自己的实现替换这些组件，诸如路由系统，视图引擎，控制器工厂等等。
ASP.NET MVC设计者对如何使用MVC框架的每个组件向你提供了三个选择：
使用默认组件实现（对于大部分应用来说已经足够了）
从默认实现继承实现一个子类，以对某些行为进行微调
使用新的接口或抽象基类实现替换这些组件
这些看起来有点像ASP.NET 2.0中的供给者模式（provider model），但它更进了一步－完全进入了MVC框架的核心。从第10章起，你将会了解到各种各样的组件，并且知道为什么要调整或替换它们。
（三） 对HTML代码和HTTP的严密控制力（Tight Control over HTML and HTTP）
ASP.NET MVC知道产生整洁、符合标准的标记的重要。它内置的HTML helper方法的输出完全符合标准，但同Web Forms相比较其更多的重要变化体现在其设计哲学上。以往你对Web Forms自动生成的一大堆令人作呕的封装的HTML标记只有很小的控制权，作为替代，MVC框架鼓励你使用CSS设计简洁、优雅的标记。
当然，如果你想在你的页面摆上一些现成的复合UI元素的小玩意，像日历或级联菜单，ASP.NET MVC中的“无特殊要求”的标记方法让你可以轻易的使用最好的UI库，比如JQuery或雅虎的YUI库。微软已经把JQuery内置为ASP.NET MVC默认项目模板的一部分，JavaScript程序员会对ASP.NET MVC和当前流行的JQuery库结合如此紧密感到欣慰，甚至在微软自己的内容分发网络（CDN）服务器上你都可以直接引用Jquery.js文件。我们将在第20章涉及到JQuery。
ASP.NET MVC生成的页面不包含任何视图状态数据，因此它们比典型的ASP.NET Web Forms页面会小数百K。尽管今天的宽带连接已经非常快了，但这种带宽的节约依然会给最终用户带来巨大的体验改善。
和Ruby on Rails一样，ASP.NET MVC和HTTP合作和谐。你对往返于浏览器和服务器之间请求拥有完整的控制权，这样你就按你的喜好可以微调你的用户体验。AJAX现在实现起来很简单，而且没有任何影响客户端状态的自动回发。关注Web开发领域的任何开发者几乎肯定会发现，ASP.NET MVC会极大减少工作量，在同样的时间内完成的任务会更加令人满意。
（四） 易测试性
MVC使你在应用程序的可维护和可测试方面迈出了一大步，因为你可以自然的根据程序要实现的不同功能将其分离成许多不同的、相互独立的软件块。然而，ASP.NET MVC的设计师们并不满足于到底就止步了。为了支持单元测试，他们在框架中引入了面向组件设计的概念，并确保每个分离的代码块都以满足单元测试和模拟工具的需要的形式构建。
出于为开发者考虑的角度，他们还在Visual Studio向导中增加了创建单元测试向导，它可以使用许多开源的单元测试工具，如NUnit和xUnit，甚至微软自己的MSTest。即使你以前从来没有写过单元测试代码，你也会有一个良好的开始。
本书中，你会看许多为ASP.NET MVC控制器（controller)和行为(action）编写的简洁、简单的单元测试示例，这些示例会使用各种测试和模拟策略来冒充框架组件的实现，以确定实际运行中可能出现的任何情况。
易测试性不只是体现在单元测试中，ASP.NET MVC应用程序和UI自动化测试工具之间工作也非常好。你可以模拟用户交互的情景编写测试脚本，再不用去猜测HTML元素的结构，使用的CSS类，或者框架将要生成的ID，也用不着担心页面的结构会出现莫名其妙的变化。
（五） 强大的路由系统
URL的风格伴随着Web应用技术的发展也在不断发展。像下面的URL：
/App_v2/User/Page.aspx?action=show%20prop&prop_id=82742
将会逐渐稀少，它将被一种简单的、整洁的格式所代替，就像下面的这个：
/to-rent/chicago/2303-silver-street
之所以关注URL的结构问题，有以下几个很好的原因：第一，搜索引擎给在URL中搜索关键字分配了很大的权重。搜索“芝加哥的租金”会更容易匹配上面那个简单的URL。第二，现在许多网络用户的理解能力足够搞明白一个URL的意思，而且他们很欣赏在浏览器地址栏输入地址时的智能导航选项。第三，当人们理解了一个URL的结构，他们更有可能去链接它，把它和朋友共享，甚至可以通过电话大声的读出来。第四，它不会把你的应用程序的技术细节，目录，文件名结构公开到整个互联网上，因此，你可以自由的改变底层的实现而不会影响到你已经拥有的连接。
早期的框架难以实现精准的URL，不过ASP.NET MVC默认使用System.Web.Routing命名空间很容易提供精准的URL。它可以让你控制你的URL的样式，并将其和你的应用相关联，为你提供创造一个有意义的、对用户有用的地址样式的自由，不需要遵守预定义的模式。另外，只要你愿意，你完全可以容易的定义时髦的REST风格的URL样式。你会第11章看到一个详细的路由方案和关于URL的最佳练习。
（六） 构建于ASP.NET平台最好的部分之上
微软现有的ASP.NET平台已经为开发实用和高效的web应用程序提供了一整套成熟的、久经考验的组件和工具集。
首先也是最明显的地方，因为ASP.NET MVC构建在.NET平台之上，所以用户可以灵活的使用任意.NET语言编写代码和访问相同API功能－不光是MVC里面的，也包括大量的系统.NET类库和浩瀚的第三方.NET库。
其次，现有的ASP.NET平台的一些功能－比如母版页，表单验证，成员资格，角色，profiles，还有国际化－能够减少你需要开发和维护任意应用程序的代码量，这些功能在MVC框架中同样有效，因为它本来就是一个杰出的Web Forms项目。你可以在ASP.NET MVC的项目中继续使用一部分Web Forms内置的服务器控件，以及你在早期的ASP.NET项目中创建的自定义控件。（不过不能再依赖Web Forms中的特有概念，比如视图状态）
开发和布署是交替进行的。ASP.NET不仅和Visual Studio紧密结合在一起，它也作为一种原生的web编程技术为Windows XP,Vista,7和服务器操作系统中安装的Internet信息服务（IIS）所支持。IIS7发布后，将.NET托管代码它的请求处理管道的原生部分，为其提供第一流的支持，这也是ASP.NET的特殊待遇。因为MVC应用基于ASP.NET平台核心，因此它也会同样享受这些待遇。第23章我们会详细说明如何在Windows服务器上的IIS中部署MVC应用程序。
（六） 现代化的API
自微软2002年发布 .NET平台以来，它一直在持续的发展，支持甚至是定义了现代编程技术顶级水准。
ASP.NET MVC是专为.NET 4.0打造的，所以它的API可以使用最新的编程语言和运行时创新的所有益处，包含扩展方法，lambda表达式，匿名和动态类型，语言集成查询（LINQ）。许多MVC框架的API方法和编码模式尽可能的比早期平台整洁，更富表现力。
（七） ASP.NET MVC是开源的
和微软先前的平台不同，ASP.NET MVC的原始代码你可以随意下载，甚至可以对其进行修改，重新编译为你自己的版本。当你的调试足迹深入到一个系统组件内部，想对它的代码进行步进（甚至阅读原作者的注释）时，代码开源是非常有用的。另外，如果你想构建一个更高级的组件，看看可能会发生什么，或者观察内置组件是如何工作的，这点也非常有帮助。
同时，如果你不喜欢某些工作的实现方式，或者你发现了一个错误，又或者你想访问一些其它方式无法访问的东西，开源好处是非常强大的。因为你自己就可以简单的改变它。
不过，如果将来有一天你将你的框架升级到新版本，你还要重复你所作的改变再重新应用它们。ASP.NET MVC是按照微软公共许可（Ms-PL，http://www.opensource.org/licenses/ms-pl.html）发布的，这是一个经过开源促进组织批准的开源许可。也就是说你能够修改源代码并部署它，甚至把它作为一个衍生项目向公众发布。然而，微软在其官方版本上不接受任何补丁，现阶段，微软只维护其产品开发和质量保证团队的负责的代码，你可以从http://aspnt.codeplex.com/网站上下载MVC的源代码。
四 谁应该使用ASP.NET MVC?
与许多新技术一样，ASP.NET MVC存在的现实并不代表我们就要非用不可。这里，我们将把MVC框架和最常用的替代品一一比较，并给出我们的意见。我们两个人在写这本关于MVC框架的书时尽我们所能保持公正，但我们知道从客观出发这肯定有局限性。下面的比较我们都是从技术角度出发的。当你选择一个web开发框架时，你还要同时考虑你的团队的经验问题，移植现有项目的工作复杂度，你在其中的关系，信心度，技术源等等。
（一） 和ASP.NET Web Forms比较
我们在前面已经详细说明了传统ASP.NET Web Forms的不足和局限，并介绍了ASP.NET MVC是如何解决了这其中大部分的问题。不过这并不是说Web Forms就死定了。微软已经一再重申会同时支持这两种技术并使它们不断发展，并且微软也没有让Web Forms退休的计划。从某些方面看，在这两者之间作出选择是一个开发理念的问题。需要考虑以下的观点：
Web Forms的观点是用户界面应该是有状态的，为此，它在HTTP和HTML之上增加了一个复杂的抽象层，使用视图状态和自动回发机制，以创建有状态的效果。这让它具备了Windows Forms相类似的拖拉开发风格，将UI组件拖到页面上，然后在它们的事件处理函数中填入代码。
MVC接受了HTTP天然的无状态性，既然打不倒它，还不如和它合作。MVC框架需要你理解web应用程序是如何真实工作的。基于这种认识，可以让你简单的、强大的、现代的方法去开发应用程序，随着时间的推移，整洁的代码易于扩展和维护，从那些离奇的迸发症和痛苦的局限中解脱出来。
肯定有案例能证明Web Forms和MVC一样好，可能比MVC还好。最明显的例子就比如一个小型的，intranet化的应用，而它的主要功能就是将数据库中的数据表绑定到网络中或者一个指引用户的向导。当你不必为带宽担心或要为搜索引擎优化时，Web Forms的拖拉式开发方式完全可以弥补它的不足。
另一方面，如果你正开发互联网应用或较大的Intranet应用程序，你会被MVC提供的更高的带宽效率，更好的浏览器兼容性，对自动化测试的更好支持所吸引。
（二） 从Web Forms迁移到MVC
如果现在你手头有一个ASP.NET Web Forms项目并考虑将其迁移到MVC上，我想你会很高兴知道这两种技术能够同时并存于同一个应用程序。这让你能够以一种平坦方式迁移你现有的应用程序，特别是如果你的应用程序按照领域模型和商业逻辑分层分成不同的Web Forms页面。
在有些项目中，你可能会故意的在一个应用程序中混合使用这两种技术。
（三） 与Ruby on Rails的比较
Rails已经成为一个衡量其它web平台的基准。Microsoft.NET领域的开发者和公司将会发现ASP.NET MVC更容易接受和学习，而使用Python或者Ruby在Linux或者是Mac OS X上工作的开发者和公司会认为Rails更容易。要人家从Rails迁移到ASP.NET MVC上这不太现实，反之亦然。这两种技术在某些方面具有本质上的区别。
Rails是一个整体的开发平台，这就意味着它要处理全部的协议栈，从通过ORM操控数据源到使用控制器和行为处理请求－这些都可以封装内置的自动测试工具。
ASP.NET MVC框架把关注点聚焦于在基于MVC模式通过控制器和行为处理web请求上，它没有内置ORM工具，自动测试工具，以及管理数据库迁移的系统。因为.NET平台已经为这些功能提供了无数的选择，你可以随意使用。比如你要找一个ORM工具，你就可以使用Nhibernate，Subsonic，微软的EF（Entity Framework），或者其它许多成熟解决方案之一。这些都是.NET平台提供的豪华功能，不过这并不代表ASP.NET MVC像Rails那样将这些组件紧密的集成到其中。
（四） 与MonoRail的比较
Mono是一个早期的基于.NET的MVC web开发平台，是2003年开发的开源项目Castle的一部分。在许多地方，MonoRail都有ASP.NET MVC的影子。MonoRail演示了一个类Rails的MVC体系如何构建于ASP.NET之上，并使用微软现有的模型，业务和术语。
这里我们并没有把MonoRail作为一个正规的竞争者。它可能是Redmond创建的最受欢迎的.NET web应用程序平台，在当时也确实很流行。不过，自ASP.NET MVC发布之后，就很少能听到MonoRail的声音了。.NET web开发领域现在把他们的热情和创新精神都集中在了ASP.NET MVC上了。
五 ASP.NET MVC 3中的新内容
MVC3中值得大书特书的特色就是Razor视图引擎的引入。先前的MVC版本主要依靠标准的ASP.NET视图引擎，使用ASP.NET中的<%和%>代码块（如果你使用ASP.NET做过开发，你肯定会见过它）。
Razor视图引擎使用特殊的@字符替换传统的代码块。新的标记方法比老的视图引擎写起来更方便，编译得也更快。它还更灵活，可以更好的应用单元测试。
你依然可以使用先前的方法写代码，不过微软的团队已经明确表示Razor是MVC的将来。实际上，本书中所有的示例都是使用Razor编写的。
Razor不是MVC3的唯一增强功能，Visual Studio的项目工具更趋合理，对依赖注入的支持更好，它还改进了对JSON数据格式和JavaScript的支持，包括紧密集成了JQuery。
六 结语
本章中，我们简单描述了Web开发技术如何以惊人的速度发展，从原始的CGI到最新的高性能，符合标准，灵活的平台。我们回顾了自2002年微软一直作为其主要Web开发平台的ASP.NET Forms的优点、不足和局限性，以及微软为应对世界web开发产业的变化而推出的新东西。
你也看到了ASP.NET MVC平台如何解决了ASP.NET Web Forms的不足，如何将现代化设计思想的优势传递给想写出高质量，可维护的代码的开发者。
下一章，你将在实践中学习MVC框架，简单的了解这种机制所产生的益处。在第7章，你将会为构建一个应用了清晰的体系，适当的关注分离，自动化的测试和优美的标记等特色的现实的电子商务网站作好准备。