MVC设计模式的介绍

继续程序入门介绍系列，这次来说一下稍微复杂的东西。

一、Unity项目使用框架有什么好处

以前有段时间我很喜欢在qq群里面回答问题，后来渐渐的也没太多时间回答了，所以变成了偶然看看别人讨论的过程。我后来发现，很多朋友都只是注重功能的实现，当实现了某个功能之后，就很高兴，觉得自己已经达到了一定的水平了。甚至有朋友直接的说，我能实现功能就够了，用Unity开发根本不需要用什么框架。

出现这种思想，我觉得有很大一部分原因是Unity官方造成的。因为Unity引擎在刚推出来的时候，宣传的是组件拼装的思想，而大部分demo都是针对某个具体功能展示而制作的。

所谓的组件拼装思想，就是我有一个空的GameObject，只带了最基本的Transform组件，可以控制位移旋转缩放。如果用户需要在上面添加功能，就可以添加相应的组件。比如我需要把一个空物体变成摄像机，只需要在空物体上面添加Camera组件，如果想这个摄像机同时有碰撞的功能，就再在上面加多个Collider碰撞组件，如果想这个物体顺便会发光，那就再添加一个Light的组件。假如需要更复杂的功能，可以自己写一个继承MonoBehaviour的脚本挂上去，因为MonoBehaviour脚本对于Unity来说也是一种组件。这样用户就可以抛弃面向对象的子类继承基类之类的繁琐结构，直接通过编辑器界面实现各种自由的功能。

所以，Unity引擎刚推出来的时候是偏向于给美术和策划用的，很多所见即所得的功能让你很简单就能实现想要的功能，很适合做规模较小的独立游戏。所以在这个阶段，Unity的确用不用框架好像没多大的区别。

但随着Unity的快速兴起，很多厂商开始拿Unity来做一些大型的项目。这个时候，很明显单一的功能实现已经不能满足项目的需要了。因为大型项目一般不会为某个功能的实现而发愁，更注重的是项目的清晰、易于维护和扩展等问题。由于有规模的项目都是多人协助一起写的，所以更需要注意项目代码的结构和质量。

好的代码标准，一般来说是高内聚，低耦合。我们需要把功能分离，让各人写的代码互不影响又能互相支持，可以单独的修改或者维护某一部分的代码而不影响到其他功能，代码可以重复利用，等等。为了达到这些目的，我们会使用一些设计模式，设计游戏的框架。

MVC是解决这个问题比较常见的一种设计模式，它不是一个具体的框架，而是一种设计的思想。可以根据这种设计的思想，写出适合项目用的框架。

二、MVC设计模式的特点

举一个稍微具体一点的例子来说明，我们现在需要做一个功能，可以在界面上面输入新增用户数据，然后列表显示出来。

如果是最简单的实现，我们可以只建立一个类，然后写代码实现三部分功能：

1、建立一个List来存储用户数据。

2、在类里面绘制一个显示列表来显示现有的用户数据，并绘制一个输入框和一个按钮来新增用户数据。

3、写一个添加用户数据的方法，把输入框的内容添加到用户数据的List。

这样就把这个功能实现了。但假如我需要对需求做一些改变，比如我需要修改一下显示列表的位置和大小，或者我需要给数据存储加一个防止重复的功能，或者这个用户数据需要在其他功能也用到。在需求变动的情况下，这个类本身就需要不停的改变。等功能复杂到一定程度之后，这个类可能就会非常臃肿而难于维护了。

为了解决这个问题，我们可以尝试着把这个类拆分一下。

我们把一个类拆成三个类，分别是view类、model类和controller类。

view类里面写了现实列表的绘制方法，还有输入框和按钮的绘制。可以通过事件通知它数据改变而刷新界面上的数据显示。

model类里面写了用户数据的存储List，提供查询方法，还有数据变化时向外抛事件通知别人。

controller类里面写了按钮触发的方法，可以把view类输入的新增用户写到model里面。

这样分割了之后，某些功能相对的就稳定下来了。当我只需要调整界面外观时，我可以单独的修改view类，其他功能想使用用户数据，可以直接访问model类取得，而需要对操作过程加特殊的方法，只需要单独的修改controller类。另外一个好处是，这样在其他层面的逻辑还没写好之前，单独的层面就可以先编写。比如我还没确定这个界面样式是怎样摆放的，但我可以先把控制层和数据层写好，等显示界面层做好了之后，接入一下就行了。

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。一般的理解model层是数据的存储，view是界面的展示，controller是控制输入逻辑。

上面这个例子简单了介绍了MVC模式的工作原理，核心的思想就是，把功能分层，特别是把显示和数据分开，然后用另外一个层级让它们2个层级联合起来工作。

三、MVC模式的进化

MVC的确是现阶段广泛应用的一个设计模式，有很多使用这个模式写的框架。在使用过程中，会根据一些实际的情况去修改一些结构上的东西。

比如，MVC虽然是把功能分层了，但从最传统的MVC结构来说，View层是可以访问Model层的，比如View层可以直接去Model层查询数据并刷新自己的界面。这个时候，会发现三个层面是形成了一种三角的关系，有时候会存在需要同时维护三个层面的逻辑交互关系。

于是，后来MVC发展出了MVP(Model-View-Presenter)模式。这个模式里面，切断了Model层和View层的关联，view层只和Presenter层交互，再通过Presenter层和Model层交互。

这样，Model和View层就完全切断了关联，大部分的逻辑实现出现在Presenter层里面。而Presenter层通过向View层提供接口方法，实现了数据的查询和刷新等功能。这样做之后，当某个层面出现了修改的需要，他都只需要和Presenter层交互，所以不需要影响到另外一个层面。

MVC模式发展的另外一个方向，是MVVM(Model-View-ViewModel)。这里提出了一个叫做ViewModel的层面，一个View的类，一般会对应一个单独的ViewModel类，这个类完全为对应的View类服务，包括了View上面每一个显示数据的刷新显示、输入逻辑等等。然后ViewModel类再和Model类做交互。这样的情况下，在没有View类的情况下，ViewModel类已经完全可以实现了所有功能，只是没有把界面绘制出来而已。当有了View类，数据自然而然就会显示在界面上面了。

MVVM模式的2点比较突出的优点，第一是数据绑定，通过ViewModel层自动更新View层和Model层。第二是可以做界面功能的自动测试。因为在完全不需要显示View显示的情况下，通过调用ViewModel提供的各种接口，你等于已经完整的操作这个界面了。

四、一些个人看法

上面说了这么多MV什么的模式，估计都看懵了吧？实际上不管是MV什么，表达的核心思想都是一样的，显示层和数据层必须分离，然后第三层的作用都是用于沟通这两个层的。至于在实际应用中他们的关联交互程度应该具体怎样写，还是需要看你对这些设计模式的理解，还有你项目的具体需要。

对于新手来说，起码能有分层的概念，先可以看懂别人的框架结构。然后在使用别人的框架做功能的时候，可以根据分层的思想，把代码集中在对应的层面去编写。最后，在学习了现有的框架的写法之后，可以尝试着自己去写一些简单的框架，再一步一步的完事，就可以拥有一套属于自己的框架了。