第一章
伟大的思想
ASP.NET MVC是来自于微软的整合了有效性的和整洁的模式-视图-控制器（MVC）架构的一种Web开发框架，它的最新的思想和技术来自于敏捷性开发，是最好的ASP.NET平台。ASP.NET MVC是传统ASP.NET Web窗体的完整替代品，为所有烦琐的网页开发项目提供了相当大的优势。在这一章，您将学习为什么微软最初创建ASP.NET MVC，如何同它的前辈比较和替换，最后，将介绍ASP.NET MVC 3的新技术。
Web开发的简史
为了了解ASP.NET MVC 独特的方面和设计目标，Web开发的历史到目前为止虽然简短但还是值得考虑的。多年来，微软的Web开发平台已经证明提高效率，但不幸的是却提高了复杂性。如表1-1所示，每一个新的平台都解决其前身的具体缺点。
表1-1 微软Web开发技术的传承
|
阶段 |
技术 |
优点 |
缺点 |
|
侏罗纪时代 |
Common Gateway Interface通用网关接口（CGI） |
简单，灵活，唯一的选择 |
外部运行Web服务，因此为资源密集型（每一个请求都要申请一个系统进程），低水平的 |
|
青铜时代 |
微软互联网数据库连接（IDC） |
内部运行Web服务 |
只是一个封装的SQL查询和格式化的结果集模板 |
|
1996 |
Active Server Pages (ASP) |
万能，通用 |
运行时解析鼓励“意大利面条式代码” |
|
2002/03 |
ASP.NET Web窗体1.0/1.1 |
编译，“状态”界面，大量的基础设施，鼓励面向对象编程 |
沉重的带宽 难看的HTML 无法测试的 |
|
2005 |
ASP.NET Web Forms 2.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 |
传统的ASP.NET Web窗体
ASP.NET是一个巨大的转变自从在2002年首次出现以来。图1-1阐明了微软的技术堆栈正是由于它的出现产生的。
|
ASP.NET Web窗体 一套UI工具（页，按钮等）加上功能强大的面向对象GUI编程模式 |
|
ASP.NET 在IIS中承载.NET应用程序的一种方法，让你与HTTP请求和响应交互 |
|
.NET 一个多国语言管理代码平台 |
图1-1 ASP.NET Web窗口技术堆栈
在Web窗体，微软尝试用一个服务器端的控制对象作为一个可继承的UI建模，以便于将http（由于它本身的无状态性）和html（因为有时候对于很多开发者来说不熟悉）隐藏起来。每一个通过请求的控制流的持续追踪都在于它自身的状态(使用视图状态的简易性)，在需要时呈现为HTML并自动连接客户端事件与相应服务器端事件处理程序代码。实际上，Web窗体是一个巨大的抽象层，旨在网络上提供一个典型的事件去驱动图形用户界面（GUI）。
当时的想法只是为了使Web开发能同窗体开发感觉一样。开发者不再需要同一系列独立的HTTP请求和回应打交道；我们现在能在服务条款中考虑状态界面。我们可以忘记Web和它的无状态性质，使用托方式设计代替建立用户界面，想象或者至少假装一切都发生在服务器上。
ASP.NET Web窗体有什么错误？
传统的ASP.NET Web窗体开发是一个伟大的思想，但实践中却是复杂的。久而久之，用户在Web窗体实际项目中突显了一些缺点：
View State负担：为维护机制状态通过请求结果需要大量的数据块在客户端和服务器端转换。这些数据甚至在一般的网页应用中能达到数千字节，每个来来回回的请求，漫长的请求时间令网站访问者沮丧同时也增加了服务器的带宽需求。
页面生命周期：用于连接客户端事件和服务器端事件处理程序代码的机制，部分页面生命周期显得格外的复杂和微妙。少数开发者已经能在程序运行时成功地操纵控制继承没有视图状态错误或发现一些事件执行处理程序神秘的失败。
不能很好的分离关注点：ASP.NET的代码隐藏模式提供了一个意味着把应用程序代码与HTML标记代码分离放进一个单独的代码隐藏类中。逻辑和表现的分离被广泛的认同，但实际上，开发者却被鼓励表现代码和逻辑代码混合在相同的源代码类中。最终的结果肯定是难以理解的。
HTML控制受限：服务器控件呈现的HTML不一定就是你所要的HTML。在ASP.NET 4之前，输出的HTML通常很难服从Web标准或很难很好的使用CSS，服务器控件生成的不可预测和复杂的控件ID名称值很难用JavaScript访问。这个问题在ASP.NET 4中有所改进，但它
对于要获得你希望的HTML仍是棘手的。
抽象漏洞：Web窗体试图在任何可能的地方隐藏HTTP和HTML的细节。当你试着自定义工具时，常常会忽略了抽象，迫使你用逆反工程的方法来处理回发事件机制或者执行迟钝的行为来实现想要的HTML。再者，所有的这些抽象行为就是Web开发者的障碍。
低可测试型：ASP.NET设计者无法预料自动化测试将成为软件开发中的不可缺少的部分。这并不奇怪，紧耦合的架构不适合单元测试。集成化测试也是一种挑战。
ASP.NET 也在一直的发展。2.0版本增加了一系列标准应用程序组件来减少开发者的代码量。微软的Web 2.0/AJAX响应了2007年出现的AJAX，支持丰富的客户端交互，让开发者的生活简单化。最新的版本，ASP.NET 4，产品更具可预见性同时也符合国际化标准的HTML标记，但是大部分本质的局限还是存在的。
如今Web 发展
微软除外，自从Web Forms首次发布以来，网页开发技术就快速发展而且是多方面的。出了AJAX，其他的都有了很大的发展。
Web标准和REST（表征状态转移（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格）
近年来，遵守Web开发标准的驱动在增加。网站面临比以前更多种多样的设备和浏览器，同时Web标准（如HTML,CSS,JAVASCRIPT等等）依然保留着无论在哪里甚至在互联网上也能享受体面的浏览体验的伟大希望。现代化的网页开发为了遵守Web标准已经不能忽略商业案例和开发者的热情。
与此同时，REST成为主要的架构通过了HTTP应用程序互操作型，彻底掩盖了SOAP（简单对象访问协议（SOAP，全写为Simple Object Access Protocol）是一种标准化的通讯规范，主要用于Web服务（web service）中）。REST描述了一个在资源方面的应用（URI）来代表真实世界的实体和标准操作（ HTTP方法）代表了在这些资源中可操作性。例如，你可以把
一个新的http://www.example.com/products/lawnmower或者删除http://www.example.com/customers/arnold-smith。
如今，Web应用程序不只是HTML服务；它们常常服务于JSON或者XML数据的客户端技术包括AJAX，Silverlight，和智能手机应用程序。这一切的发生自然来自于REST，排除了Web服务和Web应用程序历史性的区别—--但是需要一个HTTP方法和URL处理不容易被ASP.NET Web窗体支持。
敏捷和测试驱动开发
在过去的十多年中不仅Web开发在发展，软件发展也趋向于完全地敏捷开发方法。这意味着很大不同的东西，但大量地发现运行程序为了适应程序的运行，抵制累赘和限制过度的长远计划。敏捷开发方法为了促进和协调实践，趋向于同一套固定的开发实践和工具（通常为开源的）并行开展。
测试驱动开发（TDD）和它的化身行为软件开发是两个明显的例子。主要的思想是通过描述想要的行为（称为测试和规格）的例子来设计你的软件，在任何的时候，能验证程序的稳定性和正确性通过对实施执行的一套规格。.NET工具都支持TDD/BDD，但是这些往往不能很好地在WEB窗体中工作。
部分测试工具能单独指定独立的类行为或者其他孤立代码单元。它们被设计为能有效运行在程序中的一套独立的模块，因此每一个测试都能被独立运行。不幸的是，很少有web窗体程序能用这种方式测试。在框架的指导下，事件处理逻辑甚至是直接使用服务器控制数据查询，开发人员通常都把他们的程序逻辑紧紧耦合在Web窗体开发环境中。这就使得单元测试无法开展。
UI自动化工具对比程序中的运行实例来模拟一系列用户交互。理论上说，这些能在Web窗体中使用，但是无论什么时候它都会对页面布局造成轻微的损害。如果没有细心注意，Web开始产生的全部HTML结构和元素ID，使得现在的测试无计可施。
.NET开源资源和ISV（软件独立开发商）社区生成了无数的高质量的单元测试框架（NUnit和XUnit），模拟框架（Moq and Rhino Mocks），控制反转容器（Ninject and AutoFac），持续集成服务器（Cruise Controland TeamCity），对象关系映射器（NHibernate and Subsonic），等等。这些工具和技术的支持者达到了共识，在共同标志ALT.NET下发表和组织会议。传统的ASP.NET Web窗体由于单独的设计因此对于这些工具和技术是不支持的，无奈来自各行的专家和业内人士的压力，Web窗体对其有了起码的尊重。
Ruby on Rails（Ruby on Rails 是一个可以使你开发，部署，维护 web 应用程序变得简单的框架）
在2004年，Ruby on Rails还是个不为人知，为开源资源做贡献的默默无闻者。突然间转变为了Web开发的规则。Ruby on Rails不仅包含了革命性的技术，它的思想携带了现有的成分同时也以一种引人注目的，打动人心的方式进行混合，就如同把所有的现有的平台进行了整合。
Ruby on Rails（或者Rails通常也这样叫）围绕着MVC架构。通过应用MVC和协同HTTP协议工作来代替反对它，通过促进约定来代替必须的配置，和集成对象关系映射（ORM）工具在代码中，Rails应用程序在没有做出很大的努力下就备受关注了。就好像网站开发应该是持续的；就好像我们突然意识到必须带着武器战斗然而战争却结束了一样。
Rails展现了web标准和REST不需要太复杂。它也展现了当框架被设计为支持他们时灵活的开发和测试驱动开发（TDD）将更好的工作。其他的web开发领域也将迎头赶上。
Sinatra
多谢Rails，很快大量的web开发使用Ruby作为他们主要的编程语言。但是在一个如此密集的创新社区，Rails的代替品的出现只是时间的问题。有名的Sinatra在2007浮现。
Sinatra几乎丢弃了所要Rails标准下的基础架构（routing, controllers, views等等）只是URL模式映射到Ruby代码块。用户发出请求URL将导致一个Ruby代码块被执行，然后就是数据返回到浏览器，就是这样。这是一种难以置信的简单的web开发，但它却发现了两个主要的领域。第一，用这种方法建立的RESTful网页服务，只要工作快速进行。第二，自从Sinatra能连接广大范围的开源资源HTML模板和面向对象（ORM）技术，它常常被使用就好像基础，集合了约定的web框架来满足无论什么项目的架构需要。
Sinatra尚未采取任何严重的市场份额来自于像MVC平台的Rails。我们在这里简单的阐述下web开发行业继续趋向于简单化，因为Sinatra行为作为一种相反的力量能对其他的框架积累越来越多的核心特征。
Node.js
另外一个重要的趋势是使用Javascript作为主要的编程语言的运动。AJAX是首个向人们展现Javascript重要性的；JQuery向人们展现了Javascript能如此的强大和简单；谷歌的开源资源V8 Javascript 引擎向人们展现了它让人难以置信的速度。今天，Javascript已经成为一个重要的基于客户端的编程语言。它作为数据存储和非关系型数据查询语言，包括CouchDB和Mongo，它作为通用语言在客户端平台，如Node.js。
Node.js大约出现在2009并很快就获得了广泛的支持。机构上，它比Sinatra简单，这点上它不支持MVC模式。它以更低水平的方式请求HTTP连接到代码。它主要的创新点如下：
使用Javascript：开发商只需工作在简单的语言，来自客户端代码，通过服务器端逻辑甚至通过CouchDB或者其他类似的进行数据查询逻辑。
完全异步（Being completely asynchronous）：Node.js API根本不暴露任何通道阻塞线程来等待输入/输出（I/O）或者其他任何的操作。所有的I/O是由开始操作实施，I/O结束时即接受回调。这意味着Node.js有极高的效率使用系统资源和每个CUP能处理数百万条并发的请求。（每个cup平台只限于100多条并发请求）
像Sinatra一样，Node.js也是一项适时的技术。大多数业务都建立在有时间限制的框架中，迫切需要基于full-stack框架如Ruby onRails和ASP.NETT MVC的所有结构。Node.js在这里被提及的只是它表述了一些关于ASP.NET MVC设计行业发展。例如，ASP.NET MVC包括异步控制器（在14章描述）。这是一种方式来处理非阻塞式I/O的HTTP请求并扩展每一个CPU处理更多的请求。你将学习到，ASP.NET MVC在浏览器整合了精密的JavaScript运行代码。（18,19,20章有提及）
ASP.NET MVC主要优点
ASP.NET在业界获得了巨大的成功，但在讨论之余，其他的网站开发也在发展，即使是微软一直在为WEB Forms添砖加瓦，它的本质设计也显得陈旧了。
2007年10月，在德克萨斯州的奥斯丁开的首个ASP.NET会议，微软副总裁斯科特·格思里宣布并展示了一个全新的MVC Web开发平台，建立在ASP,NET平台的核心上，明确
了设计技术的发展作为一个直接反应就如同Rails作为WEB窗体的反应。接下来的章节描述这个新平台如何战胜Web Forams的缺陷并带引ASP.NET重回前沿。
MVC架构
区分MVC框架模式和ASP.NET MVC框架是很重要的。MVC模式不是新的模式，它可以追溯到1987年Xerox PARC的Smalltalk项目，作为Web应用程序的框架，如今它已经获得了广大的人气，有如下的原因：
MVC应用程序的用户交互遵循自然循环：用户的发出一个指令，响应应用程序更改其数据模型，并提供了一个更新到用户视图。如此重复循环。这对于Web应用程序与一系列的HTTP请求和应答的交互是如此的方便。
WEB应用程序通常以分层的形式整合许多的技术（数据库，HTML和可执行代码等等）。
这种模式的出现来自于这些组合自然映射到MVC的概念中。
ASP.NET MVC框架实施MVC模式并这样做，为关注点分离提供了改善。事实上，ASP.NET MVC对于MVC做了新的改变，它特别适合Web程序。你将学习到更多的原理和实践这个框架在第4章。
通过继承和适应MVC模式，ASP.NET MVC框架拥有强大的后盾同Ruby on Rails和其他类似的平台竞争，并带领MVC模式进入主流的.NET社区。由资本上通过开发商在其他的平台发现的经验和最佳做法，ASP.NET MVC中，在许多方面，推进超越甚至Rails可以提供。
可延伸性
台式电脑内部的组件是独立的部件只能通过标准的公共文档接口来进行交互。你能很容易的拆掉显卡和硬盘替换为不同制造商的，保证能安装进去和正常的工作。MVC框架同样也建立了一系列独立的组件来满足.NET接口或者抽象基础类，因此能够简单的替换组件，如Routing系统，视图引擎，控制工厂等等根据个人操作的不同。
ASP.NET MVC设计给每个MVC框架组件提供了三种选择：
使用默认的组件实现（能实现大部分的程序）
派生子类的默认实现，以调整其行为
用新的接口组件或者抽象基础类完全代替组件
它像asp.net 2.0中的供应者模型，但它更进一步，趋向于MVC 框架的核心。你将
学习到各种各样的组件即如何并且为什么要调整和代替，开始于第10章。
HTML和HTTP严格控制
ASP.NET MVC认识的开发清晰，符合标记标准的重要性。它内置的HTML辅助方法生产标准化地输出，但是这对于Web窗体来说也是重要的转变。代替了后台像服务器输出HTML那种的难以控制，MVC框架鼓励简洁的CSS样式标记。
当然，如果你为了复杂的UI元素如日期控件或者级联菜单想抛出一些现成的部件ASP.NET MVC中的“无特殊要求”的方式来标记，使它易于使用的最佳的UI库，例如JQuery或Yahoo YUI库。JavaScript开发人员将乐于学习ASP.NET MVC的网格与流行的jQuery库，微软也把JQuery作为一个内置默认的ASP.NET MVC项目模板的一部分，甚至可以直接引用了JQuery.js文件在微软自己的CDN（内容交付网站）服务器上 。第20章涉及JQurey。
ASP.NET MVC生成页不在包含视图状态数据，因此能比典型的ASP.NET WEB窗体少数百千个字节。尽管如今连接了快速的带宽，经济的带宽还是给用户提供经济的体验。
像Ruby on Rails，ASP.NET MVC和HTTP协调工作。你有完全的控制权控制在浏览器和服务器之间的请求，因此你能根据自己的意愿调节用户体验。AJAX变得如此简单，它没有任何的自动回传阻碍客户端状态。所有主要地侧重于网站的开发者定会发现这样的开发有很大的自由并且工作日也令人满意。
可测试性
MVC框架提供了一个良好的开端使得程序具备可维护性和可测试性，因为你自然地把不同的应用程序分开成为各式各样的，独立的软件段。然而ASP.NET MVC尚未停止在这里。为了支持单元测试，它采取了框架的面向组件设计和确保每一个独立模块被结构化以满足单元测试和模拟工具的要求。
增加的Visual Studio向导以你个人的名义建立单元测试启动项目，整合了开源的单元测试工具如NUnit和xUnit，而且还有微软自己的MSTest。即使你以前从没有写过单元测试，但这将是一个美好的开始。
在这本书中，你将看到关于如何写一个清晰的简单的单元测试的例子，为了让ASP.NET MVC控制器和行为能支持框架的组件在任何情况下模拟实现，使用各种测试和模仿策略。
可测性不仅是一个单元测试的问题。ASP.NET MVC应用程序也能和UI自动测试工具协作工作。你能在无需猜测框架将产生什么HTML元素架构，CSS类或者ID的情况下写测试脚本来测试模拟用户交互，并且不用担心结构突然改变。
强大的路由功能
路由形式已经演变成为网页应用程序技术在不断的发展。路由像/App_v2/User/Page.aspx?action=show%20prop&prop_id=82742这种形式越来越少，取而代之的是简单清晰的形式如：/to-rent/chicago/2303-silver-street
考虑这种URL结构有一些很好的理由。首先，搜索引擎对一个URL中找到的关键词有明显的权重。一个对“芝加哥租房”的搜索，更可能找到的是一个较简单的URL。其次，许多web用户现在对一个URL有了足够的领悟，并且欣赏在浏览器的地址栏中输入导航选项。第三，当某人理解了URL的结构时，他们更可能连接它、与朋友共享它、或在电话中报读它。第四，它并不会把你应用程序的技术细节、文件夹、文件名结构暴露给整个公用网，因此，你可以自由地修改底层实现而不会打断输入连接。
整洁的URL在早期的框架中难以实现，但ASP.NET MVC默认使用System.Web.Routing工具给出整洁的URL。这使你能够完全控制URL方案及其与应用程序的关系 — 使你能自由地创建对用户有意义和有用的URL模式，而无需符合预定义模式。而且当然，这意味着如果你想，你可以很容易地定义现代的REST风格的URL方案。提示：你将在第11章找到路由的整个处理和URL最佳实践。
建立在ASP.NET平台最好的部分之上
微软现在的ASP.NET平台为高效开发web应用程序提供了一组成熟的、经充分证明的组件和工具集。
首先，也是最明显的，由于ASP.NET MVC是基于.NET平台的，因此你拥有了很大的灵活性，你可以使用任何.NET语言来编写代码、可以访问同样的API特性 — 这不仅仅是MVC本身的特性，而是广泛的.NET类库、以及广泛的第三方.NET包库体系。
其次，现成的ASP.NET平台特性，如母版页、表单认证、成员、角色、特征、以及国际化等等，可以减少你开发和维护web应用程序的代码量 — 而且这些特性在MVC框架中的使用就像它们在经典的web表单项目中的使用一样有效。一些Web表单内建的服务器控件 — 以及你的早期项目中的自定义控件 — 可以在一个ASP.NET MVC应用程序中被重用（只要它们不依赖于Web表单的专用概念，如视图状态）。
也涉及开发与部署。ASP.NET不仅被紧密地集成到了Visual Studio之中，它也是建立在Windows XP、Vista、Win 7、以及Server产品中的IIS web服务器所支持的本地web编程技术。IIS自第7版起，利用对ASP.NET应用程序的特殊处理，可以把.NET托管代码作为其请求处理管道的本地部件，实现了对.NET托管代码的一流支持。由于建立在ASP.NET平台的核心之上，MVC应用程序得到了所有这些好处。第23章解释你需要了解的知识，以便把ASP.NET MVC应用程序部署到Windows Server的IIS上。
现代的API
自2002年初，微软的.NET平台经过了不懈的演变，它现在许多方面支持、甚至定义了达到最新技术发展水平的现代编程。
ASP.NET MVC 3是针对.NET 4而建立的，因此它的API可以充分利用最新语言和运行创新 — 包括扩展方法、lambda表达式、匿名及动态类型、以及LINQ等等。许多MVC框架的API方法和编码模式与早期平台相比，遵循了一种更清晰、更富表现力的写作方式。
ASP.NET MVC是开源的
与之前的微软web开发平台不同，现在你可以自由地下载ASP.NET MVC的源代码，并且甚至修改和编译你自己的版本。当你的调试深入到系统组件，并且你想步入其代码内部（甚至读取源程序员的注释），以及，如果你正在建立高级组件，并想看看有些什么开发可能性，或者想了解内建组件如何工作等等情况时，这种开源是无价的。
当然，如果你不喜欢框架的某些工作方式、如果你发现了一个缺陷、或者如果你恰恰想访问一些不能访问的东西，开源都是很棒的，因为你可以自己做一些简单的修改。然而，你需要对你的修改保持跟踪，并在你想更新到框架的新版本时，把它们重新运用起来。ASP.NET MVC工作在Ms-PL许可之下（www.opensource.org/licenses/ms-pl.html），这是一个开放源代码倡议（OSI）核准的开源许可协议，意即，你可以修改源码、部署它、甚至把你的修改公开作为派生项目重新分发。然而，微软不接受对其官方产品的补丁。目前，微软只提供其开发团队和QA团队的产品代码。你可以从http://aspnet.codeplex.com/上下载MVC源代码。
谁将使用ASP.NET MVC
如同任何新技术一样，因为其存在就必须使用它，这并不是一个充分的理由。在这里，我们将给出MVC框架与大多数流行的替代品比较所得到的我们的观点。我们作为编写一本关于MVC框架书籍的人，力图做到没有偏见 — 但我们知道，这受限于我们的客观情况。以下小节是基于技术的比较。当选择一个web应用程序框架时，你也应当考虑：在技术层面上，你团队的技能、移植现有项目所涉及的工作、你的关系、以及信心等方面的因素。
与ASP.NET WEB窗体比较
我们已经详述了传统ASP.NET Web表单的弱点与局限性，以及ASP.NET MVC如何克服了这些问题的许多方面。但这并不意味着Web表单的消亡，微软反复声明，对这两种技术都会积极地加以发展和支持，而且也没有要引退Web表单的计划。在某些方面，你对两者的选择是一种开发理念方面的事情。
- Web窗体的观念是UI应当是状态化的，并最终在HTTP和HTML之上添加一个复杂的抽象层，用视图状态和回递来创建状态化的效果。这使得它适合于“拖-放”式Windows表单风格的开发，其间，你把UI部件拖放到一个画布上，并在其中填写其事件处理器的代码。
- MVC采纳了HTTP真正的无状态本性，遵循而不是违抗它。它要求你理解web应用程序实际上是如何工作的，在理解的提前下，它提供了一种简单的、功能强大的、现代的方法，以整洁的代码来编写web应用程序，这些代码总是易于扩展和维护，并且免除了离奇的复杂性和令人痛苦的限制。
当然也有Web表单至少与MVC一样、甚至更好的一些情况。明显的例子是开发小型的、企业内部型应用程序，它大量的工作是把网格直接绑定于数据库表或通过向导对用户进行引导。当你不必担忧带宽消耗或搜索引擎优化时，Web表单的拖-放式开发优点可能胜过它的弱点。
另一方面，如果你正在编写用于Internet的应用程序，或大型intranet应用程序，那么你会被MVC所提供的带宽效率、更好的浏览器兼容性、以及更好的自动测试支持等所吸引。
从Web窗体迁移到MVC
如果你正在考虑把一个现存的ASP.NET Web表单项目迁移到MVC，你会开心地了解到，这两种技术可以并存于同一个应用程序之中。这为逐步迁移现存的应用程序提供了机会，特别是，利用域模型或事务逻辑单独地对Web表单的页面进行约束，而把应用程序分成若干层次的情况，尤其如此。
在有些情况下，你甚至可以故意把一个应用程序设计成混用两种技术。
与Ruby on Rails比较
Rails已经成为与其它web平台进行比较的一个基准。微软.NET世界的开发者和公司会发现ASP.NET MVC易于使用和学习，而工作于Linux或Mac OS X上的Python或Ruby开发者和公司会发现Rails更容易。从Rails迁移到ASP.NET MVC是不可能的，反之亦然。两种技术之间有一些本质上的差别。
Rails是一种整体开发平台，意即，它处理整个技术堆栈，从通过ORM进行数据库源控制，到用控制器和动作处理请求，所有一切都可以用内建的自动测试工具来完成。
ASP.NET MVC框架关注于以MVC模式用控制器和动作来处理web请求。它不具有内建的ORM工具、内建的自动测试工具、或管理数据库迁移的系统 — 这是因为.NET平台已经对这些功能包含了广泛的可选范围，而且你可以使用其中任意一种。例如，如果你正寻找一个ORM工具，你可以用NHibernate、Subsonic、微软的实体框架、或其它任意一种成熟可用的解决方案。这就是宽松的.NET平台 — 尽管它实际意味着这些组件确实并未像Rails那样集成到ASP.NET MVC之中。
与MonoRail的比较
MonoRail是一个早期的基于.NET MVC的web应用程序平台 — 是自2003年作为开源项目Castle的一部分来创建和开发的。在许多方面，MonoRail就像ASP.NET MVC的原型 — MonoRail演示了如何在ASP.NET上建立一个类似于Rails的MVC体系结构，并完全使用微软的实现来建立要运用的模式、实践、和术语等。
我们未把MonoRail看作为一个严格的竞争者。这可能是雷德蒙德（微软总部 — 译者注）之外创建的最流行的.NET web应用程序平台，而且在它的日子里确实取得了相当广泛的采纳 — 但自从ASP.NET MVC发布之后，已经很少听到MonoRail项目的消息了。.NET web开发领域的狂热和创新势头现在主要集中在ASP.NET MVC上。
ASP.NET MVC 3的新特征
MVC 3版的主要特性是引入了Razor视图引擎。以前的MVC版本一直依赖于ASP.NET的视图引擎，它依赖于ASP.NET的<%和%>代码块 — 如果你曾做过任意一种ASP.NET开发，你肯定看到过这种运用。
Razor引擎用@字符代替了传统的代码块。这种新符号能更快地书写、更快地编译、具有更灵活的特性，并比旧的视图引擎更易于单元测试。你仍然可以使用以前的方法，但微软团队已经清楚地表明，Raozr是MVC的未来 — 所以，我们对本书中的示例都采用了Razor。
MVC 3的增强并不只是Razor — Visual Studio项目工具也已经作了改进，对依赖性注入有更好的支持，而且改善了对JSON数据格式以及对JavaScript的支持 — 包括与jQuery的紧密集成。
小结
本章中，我们已经看到了web开发如何高速演变，从CGI可执行程序的原始沼泽到最新的高性能、标准兼容、敏捷平台。我们回顾了微软自2002开始就在使用的主流web平台ASP.NET Web表单的强项、弱点和局限性，以及迫使微软用一些新事物对其作出响应的广泛的web开发行业的变革。
我们看到了ASP.NET MVC平台如何解决ASP.NET Web表单的弱点，以及它的现代设计如何把优势交付给那些想编写高质量、可维护代码的开发者。
在下一章中，你将看到MVC框架的运转、了解获得所有这些好处的一些简单机制。到第7章，你便做好了以整洁的体系结构、适当的关注分离、自动测试、以及漂亮的最少标记来建立一个真实的电子商务应用程序的各项准备。