浅谈MVC框架的优点(翻译)

传统的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标记，但许多其固有的局限性依然存在。

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。