MVC、MVX及Unity3D中的使用

1.什么是MVC：

1.1 定义：

MVC全名是Model View Controller，是模型（Model）-视图（View）-操控器（Controller）的缩写，一种软件规划典范，用一种事务逻辑、数据、界面展现别离的方法组织代码，将事务逻辑集合到一个部件里边，在改进和个性化定制界面及用户交互的同时，不需要从头编写事务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功用在一个逻辑的图形化用户界面的结构中。

Model（模型） 是运用程序中用于处理运用程序数据逻辑的部分。
　　一般模型政策担任在数据库中存取数据。
View（视图） 是运用程序中处理数据展现的部分。
　　一般视图是根据模型数据创建的。
Controller（操控器） 是运用程序中处理用户交互的部分。
　　一般操控器担任从视图读取数据，操控用户输入，并向模型发送数据。

1.2 MVC闭环：

MVC闭环

1.3 MVC关系图：

MVC关系

简而言之，界面被分到了View，数据分到了载体Model上由Model“携带”，业务集中在Controller中，而推动业务的事件由用户与View交互，通过View向Controller发动。
举例说明：
（1）例如，在controller中，发现用户点选了柱状图，那么则用柱状图view来展示数据，而柱状图view 是有数据model的引用的，直接获取数据。
（2）例如，任何的一个View（柱状或者饼状图）上，点按下一页的操作，则直接通过其引用的数据model 查询获得对应的结果数据并展示。
（3）例如，任何一个View（柱状或者饼状图）上，点按删除数据，不能直接和数据层Model交互，而是通过事件方式，通知到Controller逻辑层，然后由逻辑层Controller和服务器或者数据库交互，并通知数据Model层发生变化，而数据Model层发生改变后，可以通过事件直接通知View刷新结果，当然也可以是Controller改变的时候，先刷新Modle数据，再调用View去显示。

1.3 MVC的缺点

在MVC模型里，更关注模型层（Model）的不变，为了让多个视图层（View）的不同显示。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。由于视图层需要持有控制层的Activity引用才能进行UI的引用和交互处理，妨碍了视图的独立重用。不仅如此，视图层（View）是可以直接访问模型层（Model）的，从而视图层不可避免会涉及一些业务逻辑。因为在View里实现的业务逻辑是无法被重用的，导致要更改和重用View变得比较困难。由于模型操作接口的不同，视图可能需要多次调用模型才能获得足够的显示数据，不必要的频繁访问未变化数据的，也损害一定性能。
还有 通俗的说，一个Modle和一个Control 对应 多View。不能实现Modle和Controller的复用。

2.什么是 MVX：

这里引用一个知乎高赞回答：M-V- X 本质都是一样的 重点还是在于M-V 的桥梁，要靠X来牵线。
在相同技术栈下 能够实现的各种 X都可以是大同小异的。
在不同技术栈下 相同的X可能实现都大相径庭，仅有非常抽象的流程类似。

2.1 MV-P（Model-View-Presenter）

2.1.1 定义

MVP即Model-View-Presenter。

image.png

image.png

Model的工作就是完成对数据的操纵，数据的获取、存储、数据状态变化都是model层的任务，如网络请求，持久化数据增删改查等任务
View只处理视图相关，不做任何逻辑处理。
Presenter作为桥梁，处理所有二者之间的中转。

2.1.2 优缺点

在这个模式下，M和V的连接被完全切断了，以前C层只是负责一些简单的转发和处理，现在P的任务变的更重，除了桥梁的作用之外，还需要做初步甚至高级的逻辑处理来处理M-V或者V-M的交流过程。如图所示：

image.png

居然P的任务变重了，那么相对来说，P也会变得更加臃肿和难以维护，但是好处是将M和V彻底解耦，不管哪一方的实现方式发生变化，只要最终和P同步的数据不变另一方都不需要关心和修改。

另外V的逻辑功能一部分移入P之后，V可以更加专注的处理自身的表现，同时因为对接是通过接口实现的，所以满足接口的各种测试或者模拟都能够得以使用。

另外这里每一个V都对应一个P，写法非常复杂，软件复杂的时候，类和文件贼多。并且它仍然没有解决M复用的问题。

2.2 MV-VM（Model-View-ViewModel）

2.2.1 定义

MVVM是Model-View-ViewModel的简写。

image.png

从图上看是比MVP简单了，更不用说MVC了。这可能是在MVP之后出现的一种“更好的”UI模式解决方案，但是用MVP来与之对比比较容易说明问题。ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel间没有了MVP的界面接口，而是直接交互，用数据“绑定”的形式让数据更新的事件不需要开发人员手动去编写特殊用例，而是自动地双向同步。数据绑定你可以认为是Observer模式或者是Publish/Subscribe模式，原理都是为了用一种统一的集中的方式实现频繁需要被实现的数据更新问题。比起MVP，MVVM不仅简化了业务与界面的依赖关系，还优化了数据频繁更新的解决方案，甚至可以说提供了一种有效的解决模式。所以我们能理解为什么许多人认为MVVM是最好的一种模式。但事实上，MVVM也是依赖于我们至今所讲的“特有的情境”。当然，最优雅的也是第一个能作代表的实践就是Windows Presentation Foundation（WPF）了。

image.png

2.2.2 优缺点

MVVM模式和MVC模式一样，主要目的是分离视图（View）和模型（Model），有几大优点：
1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。

2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。

3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。

4. 可测试。界面素来是比较难于测试的，测试可以针对ViewModel来写。

3. MVC、和（其他MVX们）MVP、MVVM设计模式和框架的区别：

MVC或者任何MVX 都是一种设计模式。

框架、设计模式这两个概念总容易被混淆，其实它们之间还是有区别的。框架通常是代码重用，而设计模式是设计重用，架构则介于两者之间，部分代码重用，部分设计重用，有时分析也可重用。在软件生产中有三种级别的重用：内部重用，即在同一应用中能公共使用的抽象块;代码重用，即将通用模块组合成库或工具集，以便在多个应用和领域都能使用；应用框架的重用，即为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。

框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。可以说，框架是软件，而设计模式是软件的知识。

框架模式有哪些？

MVC、MTV、MVP、CBD、ORM等等；

框架有哪些？

C++语言的QT、MFC、gtk，Java语言的SSH 、SSI，php语言的 smarty(MVC模式)，python语言的django(MTV模式)等等

设计模式有哪些？

工厂模式、适配器模式、策略模式等等

简而言之：框架是大智慧，用来对软件设计进行分工；设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度。

4. Unity3D中怎么用：

4.1 直接套用模式

image.png

image.png

image.png

image.png

4.2 创新改进的M-V-MV-E（Modle-View-ModleView-Event）

image.png

4.2.1 解决一个Modle对应多个View问题

对于游戏开发而言，View存在多份是很正常的，例如一份好友列表的数据，可以在好友面板展示，也可以在聊天面板展示，还可以在内容分享列表中展示。
所以是一份数据，对应多个View，所以这里可以用任何一个MVX（MVC，MVP，MVVM），都可以实现。都是一份数据Modle对应 多个View。

4.2.2 解决View复用的问题

而很多情况下，比如一个列表的展示，View的实现也大致相似，因此可以抽象出ModelView，可复用大量的view逻辑。因此可以用MVVM模式。

4.2.3 解决游戏中多模块耦合，数据统一管理的问题

由于游戏中，无论是弱联网单机游戏还是实时网络游戏，数据都来源于服务器，因此一定有个集中处理收发数据的地方，可以叫做DataProcessCenter，数据的改变，都是通过这个DataProcessCenter作为桥梁链接Server和Client。
而既然已经有了DataProcessCenter，MVX中的Modle就已经有了，无非是，各子模块中独立维护，还是DataProcessCenter统一维护。但无论是哪一种，都可以通过Event来解耦，这个可以理解成 消息-发布模式，或者观察者模式，订阅数据改变，并形成变化。

【参考1：https://zhuanlan.zhihu.com/p/157273459】
【参考2：https://www.zhihu.com/question/20148405/answer/23813147】
【参考3：https://blog.csdn.net/leehuimr/article/details/116298737】