摘要：
ASP.NET MVC是微软的Web开发框架，结合了模型-视图-控制器（MVC）架构的有效性和整洁性，敏捷开发最前沿的思想和技术，以及现存的ASP.NET平台最好的部分。它是传统ASP.NET Web Form完整的替代技术。在这个篇文章中，我将介绍为什么微软创造了ASP.NET MVC，他跟他之前的技术有什么不同。
ASP.NET历史
要想了解ASP.NET MVC的历史，需要先了解ASP.NET的历史。ASP.NET在2002年创建。他结合了ASP.NET WEB Form技术、ASP.NET IIS技术以及.NET技术。
通过WEB Forms，微软通过将用户接口（UI）建模成一系列分级的服务器端控件对象，隐藏了HTTP（和它的无状态性）和HTML（那时候很多开发者还不熟悉他）。每个控件在HTTP请求过程中保持和记录自己的状态，在需要的时候将自己呈现为HTML元素，并自动连接客户端事件（例如按钮事件）和相应的服务端事件处理器代码。实际上，Web Forms是一个设计成能在Web上发送经典事件驱动用户接口（GUI）的大的抽象层。他的想法是让Web开发感觉就像是Windows Form开发一样。开发者不需要处理一系列相互依赖的HTTP请求和响应。他们只需要关心UI逻辑，微软无缝地将Windows桌面开发者大军传送到Web应用世界。
ASP.NET缺点
- 视图状态负担：实际的在跨请求状态间的维护状态机制（View State）导致了在客户端和服务器端之间大的数据传输。传输的数据在非常简单的Web页面中都可能达到几百KB，并且在每个请求中来回传送，导致非常长的响应时间，以及增加了服务端的带宽需要。
- 页面生命周期：连接客户端事件和服务端事件的代码（一部分是页面生命周期）可能异常复杂和精细。很少的开发者能够成功地处理和控制在运行时的层级关系，而得到视图状态错误，或者出现一些事件处理器在处理器执行时奇怪地失败的情况。
- 错误的分离关注点：ASP.NET Web Form代码隐藏模型提供了一种将应用代码和HTML标记分离的方式。这种分离业务逻辑和表现的方式曾经受到广泛地欢迎。但是，在现实上，开发者被鼓励去将表现层代码和应用层代码糅合到一起到同样的怪异的代码隐藏类。（例如，将处理服务端控件树和处理数据库的代码）。导致脆弱和难以理解的结果。
- 对HTML的控制很有限：服务端控件将自己呈现为HTML，但是并不是你想要的HTML。早期的ASP.NET版本，HTML输出不符合Web标准，不能好的利用层叠样式表（CSS），服务端控件产生不可预期的复杂的ID属性值，使用JavaScript很难访问他们。这些问题在最近的Web Forms发行版本中改进了很多，但是还是会得到非你预期的难处理的HTML。
- 出现裂缝的抽象：Web Forms尝试在任何可能的时候隐藏HTML和HTTP。当你在实施客户行为时，你经常放弃这种抽象，逼迫你反过来使用会发事件机制或者使用迟钝的方式让他产生你想要的HTML。这时候，所有的WEB Forms抽象都变成了Web开发者们令人沮丧的障碍。
- 低测试性：Web Forms设计者们没有预料到自动化测试会变成软件开发过程中一个重要的部分。不出意料的，他们设计的紧密的耦合架构是不适合单元测试的。集成测试也一样受到挑战。
Web Forms不是都是不好，微软已经在提高他的灵活性上付出了很多努力，简化开发流程，甚至从ASP.NET MVC中拿了一些特性。当你需要快速开发的时候（一个相对不怎么复杂的web app一天能开发完毕的时候）Web Form更胜一筹。但是除非你在开发的时候非常仔细，否则你将发现你创建的应用程序非常难以测试和维护。
ASP.NET MVC主要优点
在2007年十月，微软宣告了一个新的MVC开发平台，建造在ASP.NET核心平台之上，清楚地设计成适应革新技术（例如Rails）以及Web Form批评者们的直接响应。下面部分描述新的平台怎样胜过Web Forms的以及怎样将ASP.NET技术重新带到了时代边沿。
区分MVC架构模式和ASP.NET MVC框架比较重要。MVC模式不是新东西-往回到1978年在Xerox PARC的Smalltalk工程-但是现在作为一个模式，他获得了Web应用的巨大的欢迎。有下面几个原因：
- MVC架构
用户跟MVC应用交互按照自然的循环：用户发出一个行为，作为响应系统改变它的数据模型，发送更新后的视图给用户。然后重复循环。这对发出一系列的HTTP请求和收到响应的Web应用非常便利。
Web应用迫使组合一些技术（例如：数据库，HTML和执行代码），将他们分开到不同的层中。从组合这些层的过程中产生的模式自然地映射成了MVC概念。ASP.NET框架实现了MVC模式，在实现过程中，改善了关注点的分离。事实上，ASP.NET MVC实现了MVC模式相当部分的内容，特别适合Web应用。
- 可扩展性
MVC框架建造于一系列的相互独立的基于.NET接口的组件上，并基于抽象基类。你可以非常容易地替换组件，例如用不同的你自己实施的组件替换路由系统、视图引擎和控制器工厂。大概来说，MVC框架给你三个选项：
- 使用默认标准的组件（对大部分应用来说足够了）
- 使用继承类替换默认的组件行为
- 使用新的基于接口和抽象类的组件替换默认组件
紧紧地控制HTML和HTTP
ASP.NET产生干净，标准的标记HTML。基于HTML帮助类方法产生符合标准的输出，但是有一个相对于Web Forms更具有哲学意义上的改变。不是产生一片你不能控制的HTML，MVC框架鼓励你手工写简单优雅的用CSS装饰的标记。
当然了，如果你不想扔掉一些现成的复杂的UI元素小部件，例如日期控件或者层级菜单，ASP.NET MVC很容易使用最佳的UI框架例如jQuery UI或者Bootstrap CSS框架。
ASP.NET MVC 产生的页面不含有任何视图状态数据，因此他们比ASP.NET WEB产生的页面更小。
ASP.NET MVC与HTTP无缝工作。你可以控制在浏览器和服务端之间传递的请求，因此你可以尽量细微地控制你的用户体验。AJAX变得很容易，没有了任何自动的从客户端到服务器端接口的回传。
可测试性
MVC架构让你的应用程序开始有可维护性和可测试性，因为你自然地分离了不同的应用程序关注点。然而，ASP.NET设计者们并没有停留在这里。为了支持单元测试，他们使得框架设计成为以组件为目标的设计，确保每个分开的部分都能够服务单元测试和Mocking工具的需要。
可测试性不只是单元测试。ASP.NET MVC应用程序也可以很好的和UI自动化测试一起工作。你可以写测试脚本模仿用户操作而不用去担心操作的是哪一个HTML元素、CSS类或者框架产生的ID，而且你不用担心页面HTML结构无预期的变化。
强大的路由机制
随着Web应用技术的更新。URL样式也发生了变化。像这样的URL：
/App_v2/User/Page.aspx?action=show%20prop&prop_id=82742
变得越来越少了。被替换成一个更简单干净的下面的格式：
/to-rent/chicago/2303-silver-street
有一些好的关心URLs结构的原因。首先，搜索引擎更看重在URL上找到的关键字。搜索"rent in Chicago"更容易出现在搜索中。其次，许多Web用户现在足够理解URL，能够直接在地址烂输入URL。第三，当人们开始理解URL结构后，他们更有可能链接他，跟朋友分享它，甚至在电话里大声的读它。第四，他并没有暴露你的应用程序的技术细节、文件夹和文件名。
干净的URLs在以前的框架中很难实施，但是ASP.NET MVC使用一个称为URL路由的特性来提供默认的干净URLs。这让你可以控制你的URL模式，以及跟你应用之间的关系。让你*地创建有意义对用户有用的URLs的模式，而不用服从于一个定义好的模式。当然，这意味着你可以容易地定义一个你愿意的时尚的REST样式的URL样式。
建造于ASP.NET平台最好的部分
微软现存的ASP.NET平台提供了一个成熟的、经过检验的组件集合，适合开发有效高效的的Web应用系统。
首先最明显的，因为ASP.NET MVC是基于.NET平台的，你可以使用任何.NET语言访问相同的API特性-不仅是MVC自身，.NET扩展类框架和广大的第三方.NET框架生态圈也一样。
其次，已经做好的ASP.NET平台特性-例如验证、成员资格、角色、Profile和国际化-能够减少你在开发和维护WEB系统时的代码，并且这些特性在MVC框架里和在经典WEB Form工程里一样有效。ASP.NET平台底层为MVC框架提供了WEB开发丰富的工具集合。
ASP.NET MVC是开源的
不像以前的微软Web开发平台，你可以*地下载ASP.NET MVC源代码，甚至修改和编译你自己的版本。