精品图书推荐——最新版本《ASP.NET MVC 4 框架揭秘》

针对最新版本的ASP.NET MVC 4，深入剖析底层框架从请求接收到响应回复的整个处理流程（包

括URL 路由、Controller的激活、Model元数据的解析、Model的绑定、Model的验证、Action 的执行、

View的呈现和ASP.NET Web API等），并在此基础上指导读者如何通过对ASP.NET MVC 框架本身的

扩展解决应用开发中的实际问题。

 

图书样章抢先看：http://wenku.it168.com/d_000688972.shtml

第1 章   ASP.NET + MVC

ASP.NET MVC 是一个全新的Web 应用框架。将术语ASP.NET MVC 拆
分开来，即ASP.NET+MVC ，前者代表支撑该应用框架的技术平台，意味着
ASP.NET MVC和传统的Web Forms 应用框架一样都是建立在ASP.NET 平台
之上；后者则表示该框架背后的设计思想，意味着ASP.NET MVC采用了MVC
架构模式。

1.1 传统MVC模式
对于大部分面向最终用户的应用来说，它们都需要具有一个可视化的UI界面与用户进
行交互，我们将这个UI称为视图（View ）。在早期，我们倾向于将所有与 UI相关的操作糅
合在一起，这些操作包括UI界面的呈现、用于交互操作的捕捉与响应、业务流程的执行以
及对数据的存取，我们将这种设计模式称为自治视图（Autonomous View，AV）。
1.1.1 自治视图
说到自治视图，很多人会感到陌生，但是我们（尤其是.NET 开发人员）可能经常在采
用这种模式来设计我们的应用。Windows Forms 和ASP.NET Web Forms虽然分别属于GUI
和Web 开发框架，但是它们都采用了事件驱动的开发方式，所有与 UI相关的逻辑都可以定
义在针对视图（Windows Forms 或者Web Forms ）的后台代码（Code Behind）中，并最终注
册到视图本身或者视图元素（控件）的相应事件上。
一个典型的人机交互应用具有三个主要的关注点，即数据在可视化界面上的呈现、UI
处理逻辑（用于处理用户交互式操作的逻辑）和业务逻辑。自治视图模式将三者混合在一起，
势必会带来如下一些问题：
 业务逻辑是与UI无关的，应该最大限度地被重用。由于业务逻辑定义在自治视图中，
相当于完全与视图本身绑定在一起，如果我们能够将UI的行为抽象出来，基于抽象化
UI的处理逻辑也是可以被共享的。但是定义在自治视图中的 UI处理逻辑完全丧失了重
用的可能。
 业务逻辑具有最强的稳定性，UI处理逻辑次之，而可视化界面上的呈现最差（比如我
们经常会为了更好地呈现效果来调整HTML ）。如果将具有不同稳定性的元素融为一
体，那么具有最差稳定性的元素决定了整体的稳定性，这是“短板理论”在软件设计
中的体现。
 任何涉及UI的组件都不易测试。UI是呈现给人看的，并且用于与人进行交互，用机器
来模拟活生生的人来对组件实施自动化测试不是一件容易的事，自治视图严重损害了组
件的可测试性。
为了解决自治视图导致的这些问题，我们需要采用关注点分离（Seperation of Concerns，
SoC ）的方针将可视化界面呈现、UI处理逻辑和业务逻辑三者分离出来，并且采用合理的交
互方式将它们之间的依赖降到最低。将三者“分而治之”，自然也使UI逻辑和业务逻辑变得
更容易测试，测试驱动设计与开发变成了可能。这里用于进行关注点分离的模式就是MVC。