第1章 ASP.NET MVC背景
精通 ASP.NET MVC 5
ASP.NET MVC是微软公司的一款Web开发框架，整合了“模型-视图-控制器”架构的高效与整洁、敏捷开发最现代的思想与技术，以及当前ASP.NET平台最好的部分。ASP.NET MVC是传统ASP.NET Web Form的一个完善的替代品。除了一些微不足道的Web开发项目之外，在各种Web开发项目中，它都具有明显的优势。在本章中，你将了解微软公司当初为什么创建ASP.NET MVC，与它的前版和替代品之间的比较，最后概述ASP.NET MVC 5的新特性以及本书的内容。
1.1 理解ASP.NET历史
ASP.NET自2002年刚问世起，就是一种巨大的转移。图1-1描述了当时微软公司的技术堆栈。
注：此图的含义为Web Form建立在ASP.NET之上，而ASP.NET又建立在.NET平台之上，MVC框架所起的作用是替代这里的Web Form。
通过将用户界面（UI）模拟为服务器端控件对象层的办法，微软公司试图利用Web Form将HTTP（具有无状态本质）和HTML（当时许多开发人员尚不熟悉）都隐藏起来。每个控件都跨请求地跟踪自己的状态（通过使用View State功能），在需要时将自己渲染成HTML，并自动地将客户端事件（如按钮单击）与服务器端相应的事件处理器代码相关联。结果，Web Form被设计成一个巨大的抽象层，以便在Web上传递传统的事件驱动式图形用户界面（GUI）。
其思想是，让Web开发如同Windows Form开发一样。开发者无须使用一系列独立的HTTP请求与响应。他们可以认为这是一种状态化的UI，因而，微软公司可以让Windows的桌面开发人员向新型的Web应用程序领域实现无缝的转型。
ASP.NET Web Form的问题
传统的ASP.NET Web Form开发曾是一种了不起的思想，但事实证明它更加复杂。
视图状态（View State）重负：跨请地维护状态的实际机制导致在客户端与服务器之间传输大块数据。这种数据即使在最适度的Web应用程序中，也可能达到数百KB，而且它来回于各次请求之间，导致很慢的响应时间，并增加了服务器的带宽需求。
页面生命周期：连接客户端事件与服务器端事件处理器代码的机制（是页面的部分生命周期），格外复杂和棘手。很少有开发者在不产生View State错误或未发现某些事件处理器莫名失效的情况下，能够在应用程序运行期间成功地维护控件层。
关注分离的错误理念：ASP.NET的后台代码模型提供了一种手段，将应用程序代码从它的HTML标记中提取出来，并放到一个独立的后台代码类中。这种逻辑与表现的分离曾得到广泛的赞许，但事实上，又鼓励开发者在这些怪异的后台代码类中将表现代码（如操纵服务器端控件树）与它们的应用程序逻辑（如维护数据库数据）混在一起，最终结果是脆弱和难以理解。
HTML上的受限控制：服务器控件将自己渲染成HTML，但并不是你所希望的那种必要的HTML。在ASP.NET 4之前，这种HTML输出通常不符合Web标准，或不能很好地使用CSS（Cascading Style Sheets，层叠式样式表）。而且，服务器控件会生成不可预知且复杂的ID标签属性值，这些ID难以用JavaScript进行访问。这些问题在ASP.NET 4和ASP.NET 4.5中改善了不少，但要得到你所期望的HTML，仍需要技巧。
有缺陷的抽象：Web Form试图尽可能地隐去HTML和HTTP（这是通过Web Form的抽象层实现的）。当你试图实现自定义行为时，时常需要放弃这种抽象，这迫使你需要采取回发事件机制的逆向工程，或采取笨拙的方法（这样才可能绕过Web Form的抽象层，但给编程造成了难度），以使它生成所希望的HTML。再则，这种抽象可能对有能力的Web开发者构成一个极大的障碍（由于编程难度，给希望实现自定义行为的开发人员造成了一定障碍）。
低可测试性：ASP.NET的设计者恐怕未曾预料到，自动测试会成为软件开发的主要成分。因此，他们设计的这种紧耦合体系结构不适合于单元测试，也就不足为奇了。集成测试也很具挑战性。
Web Form也并非一无是处，微软公司投入了大量精力，以改善标准兼容性、简化开发过程，甚至从ASP.NET MVC中提取了一些特性。Web Form擅长速效，而且在一天之内就能够建立和运行一个相当复杂的Web程序。但是，除非在开发期间足够小心，否则会发现所创建的程序难以测试和维护。
注：
ASP.NET Web Form的完整细节，请参阅笔者的Pro ASP.NET 4.5 in C#一书，由Apress出版。该书涵盖整个框架，并为避免大多数严重缺陷提供了最佳实践指南。