ASP.NET MVC框架新手入门学习教程之MVC简介

传统MVC 模式

对于大部分面向最终用户的应用来说，它们都需要具有一个可视化的UI 界面与用户进行交互，我们将这个UI 称为视图(View) 。在早期，我们倾向于将所有与UI 相关的操作揉合在一起，这些操作包括UI 界面的呈现、用于交互操作的捕捉与响应、业务流程的执行以

及对数据的存取，我们将这种设计模式称为自治视图(Autonomous View, AV) 。

自治视图

说到自治视图，很多人会感到陌生，但是我们(尤其是.NET 开发人员)可能经常在采用这种模式来设计我们的应用。Windows Forms 和ASP.NET Web Forms 虽然分别属于GUI和Web 开发框架，但是它们都采用了事件驱动的开发方式，所有与UI 相关的逻辑部可以定义在针对视图(Windows Forms 或者Web Forms) 的后台代码(Code Behind) 中，并最终注册到视图本身或者视图元素(控件)的相应事件上。

一个典型的人机交互应用具有三个主要的关注点，即数据在可视化界面上的呈现、UI处理逻辑(用于处理用户交互式操作的逻辑)和业务逻辑。自治视图模式将三者混合在一起，势必会带来如下一些问题:

• 业务逻辑是与UI 无关的，应该最大限度地被重用。由于业务逻辑定义在自治视图中，相当于完全与视图本身绑定在一起，如果我们能够将UI 的行为抽象出来，基于抽象化的处理逻辑也是可以被共享的。但是定义在自治视图中的UI 处理逻辑完全丧失了重用的可能。
• 业务逻辑具有最强的稳定性， UI 处理逻辑次之，而可视化界面上的呈现最差(比如我们经常会为了更好地呈现效果来调整HTML) 。如果将具有不同稳定性的元素融为一体，那么具有最差稳定性的元素决定了整体的稳定性，这是"短板理论"在软件设计中的体现。
• 任何涉及UI 的组件都不易测试。UI 是呈现给人看的，并且用于与人进行交互，用机器来模拟活生生的人来对组件实施自动化测试不是一件容易的事，自治视图严重损害了组件的可测试性。

为了解决自治视图导致的这些问题，我们需要采用关注点分离( Seperation of Concems,SoC) 的方针将可视化界面呈现、UI 处理逻辑和业务逻辑三者分离出来，并且采用合理的交互方式将它们之间的依赖降到最低。将三者"分而治之"，自然也使UI 逻辑和业务逻辑变得更容易测试，测试驱动设计与开发变成了可能。这里用于进行关注点分离的模式就是MVC 。

什么是MVC 模式

MVC 的创建者是Trygve M. H. Reenskau ，他是挪威的计算机专家，同时也是奥斯陆大学的名誉教授。MVC 是他在1979 年访问施乐帕克研究中心(Xerox Palo Alto Research Center,XeroxPARC) 期间提出一种主要针对GUI 应用的软件架构模式。MVC 最初用于SmallTalk，Trygve 最初对MVC 的描述记录在Applications Programming in Smallta/k-80(TM) :How to use Mode/- View-Controller (MVC)这篇论文中，有兴趣的读者可以通过地址http://st-www.cs.illinois.edu/users/smarch/st -docs/mvc.html 阅读这篇论文。

MVC 体现了关注点分离这一基本的设计方针，它将构成一个人机交互应用涉及的功能分为Model 、Controller 和View 三部分，它们各自具有相应的职责。

• Model 是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型(Domain Model)。 Model 接受Controller 的请求并完成相应的业务处理，在状态改变的时候向View 发出相应的通知。
• View 实现可视化界面的呈现并捕捉最终用户的交互操作(比如鼠标和键盘操作)。
• View 捕获到用户交互操作后会直接转发给Controller，后者完成相应的UI 逻辑。如果需要涉及业务功能的调用， Controller 会直接调用Model 。在完成UI 处理之后， Controller会根据需要控制原View或者创建新的View对用户交互操作予以响应。

需要涉及业务功能的调用， Controller 会直接调用Model 。在完成UI 处理之后， Controller会根据需要控制原View 或者创建新View 对用户交互操作予以响应。

下面的图揭示了MVC 模式下Model 、View 和Controller 之间的交互。对于传统的MVC模式，很多人认为Controller 仅仅是View 和Model 之间的中介，实则不然， View 和Model存在直接的联系。View 可以直接调用Model 查询其状态信息。当Model 状态发生改变的时候，它也可以直接通知View。比如在一个提供股票实时价位的应用中，维护股价信息的Model在股价变化的情况下可以直接通知相关的View 改变其显示信息。

从消息交换模式的角度来讲， Model 针对View 的状态通知和View 针对Controller 的用户交互通知都是单向的，我们推荐采用事件机制来实现这两种类型的通知。从设计模式的角度来讲就是采用观察者(Observer)模式通过注册/订阅的方式来实现它们，即View 作为Model的观察者通过注册相应的事件来检测状态的改变，而Controller 作为View 的观察者通过注册相应的事件来处理用户的交互操作。

我看到很多人将MVC 和所谓的"三层架构"进行比较，其实两者并没有什么可比性，MVC 更不是分别对应着UI 、业务逻辑和数据存取三个层次，不过两者也不能说完全没有关系。Tηrgve M. H. Reenskau 当时提出MVC 的时候是将其作为构建整个GUI 应用的架构模式，这种情况下的Model 实际上维护着整个应用的状态并实现了所有的业务逻辑，所以它更多地体现为一个领域模型。而对于多层架构来说(比如我们经常提及的三层架构)， MVC 是被当成UI 呈现层C Presentation Layer) 的设计模式，而Model 则更多地体现为访问业务层的入口CGateway) 。如果采用面向服务的设计，业务功能被定义成相应服务并通过接口(契约)的形式暴露出来，这里的Model 还可以表示成进行服务调用的代理。