Unity框架学习笔记（一） 什么是MVC

摘自：http://www.cnblogs.com/skynet/archive/2012/03/21/2410042.html

MVC就是(Model View Controller)模型－视图－控制器，是一个设计模式（也可以称为架构模式），但目前在大部分人眼里显然并不只有这点意义。受到各种MVC框架的影响，消息通信，依赖注入，隔离编译等等概念现在都加入到了MVC的概念里，而且因为应用上的重叠和相似性，还常常和三层架构的概念混淆。

“一千个人眼中有一千个哈姆雷特”

一个名词的意义，是由人们的理解来决定的，因此这里从最基本的概念入手。

1.1.     MVC分解

对于一个用于显示的程序，最开始，只有View（视图）。

我们要获得一个数据并显示，就是写段代码调用接口，获得数据，然后根据数据更新视图。而这里的数据只是一个临时变量，或者存在于视图的某个属性中。显然，这样做的话，数据是依赖于视图的，如果不通过视图，或者视图根本不存在的时候，其他模块就访问不到这个已经返回的数据，则需要重新调用一次，这显然是一种浪费，而且也不便利。因此我们在这里将数据保存到别处，和视图不共享同一生命周期，那么这分离出来的数据则被规定为Model（模型）。

（在这里我必须打断说明下，模型!=数据，仅仅是在这个简化例子里模型==数据。模型是为视图提供内容的单独模块，具体内部是什么情况则是各种各样的，提供数据只是它的功能之一）

至此，就是最基本的分离表现层的原则。然而，有个地方却是分不开的——原来控制加载数据的这部分代码。它负责的是获取数据，并指示视图根据数据更新的任务，而它的去向有两个选择：要不加到视图上（这是通常的做法），要不加在模型上（如果需要模型对应多个视图），反正他不可能因为分离就凭空消失。那么我们把这部分代码提出来作为单独的部分，就是Controller（控制器）。

一旦分离出了控制器，联系模型和视图的具体代码就不再处于两者之上（当然调用代码还是有的），而是一个独立的部分。它有自己的名字，而且不会和其他不相关的内容混合在一起，非常清晰，容易定位。而模型和视图从此也只关心控制器，而不关心对方。他们的代码都是处理自己的事情，别人的事情全部交给控制器去办，这使得他们自己的功能也非常独立，减少了需要考虑的要素。

这只是代码位置的移动，但是这样移动后，将牵涉内容最多最易变，但是代码量最少的代码单独放入控制器中，并妥善管理。相当与将分散在房间各处的开关集中于一处，排列整齐并标注名字，做成遥控器在手里把玩，从此就能从奔波于房间各个位置，寻找隐藏在角落里的小突起的日常活动中解放出来。其意义，不言而喻。

而这，作为MVC的作用，已经足够了。

1.2.     消息通信、依赖注入等

一旦我们将视图，模型，控制器分离后，可以做到什么呢？

因为视图和模型都只用处理自己的事情，对控制器的调用只是一句代码而已，那么，它们实际上就可以被隔离出去。负责这部分代码的人只需要关心自己的事情，而不需要关心整个环境。同样的，编写控制器的人只需要知道视图和模型的对外接口，而不需要了解它们的具体实现，也就是只需要关心环境。这使得不同开发者需要的知识被分隔开，每人只需要了解有限的少量知识，最终却又能顺利合并在一起。

这是就是协作分工的基础。

在这之后，三者的关系只存在简单的调用代码。那么为了能够彻底的分离和解耦，就可以将调用代码改为发送消息或者其他的动态形式，这样就能在没有其他部分的时候独立编译。由不同人在不同的工作环境独立完成自己的部分，并在最后发布时候简单合并在一起，这确实是最理想的协作模式。

做到这点需要一个消息框架，而这就是MVC框架的主要任务。除此之外，各种不同的框架还会加入其它设计模式，提供各种附加功能，自动依赖注入就是其中一项。还可能加入其它的中间件，进一步分割层次，诸如分离出视图其中的逻辑部分，使得绘图和位置代码不会和逻辑代码混合，方便分工以及修改。使用观察者模式，使得数据部分的修改可以自动同步到视图上，如此这般……MVC框架指的是“实现MVC的框架”，而非“只实现MVC的框架”，仅仅实现MVC，这个框架的功能太过贫乏了，毕竟MVC也就是那种程度的东西。

最终，完成了这些之后，就成为了一般人表面看到的东西。虽然各式各样，我们都将其称之为“MVC框架”。