Intro
在最早的时候，软件开发并不区分什么叫作视图层，什么叫作数据层，所有的内容都是混在一起的。
在小的项目中，这样做并没有什么不好，但当项目的规模大起来时，项目的复杂度会以不断增加，最终屎山会将开发项目的程序员压垮。
在维护屎山时，程序员们发现，如果将数据和表现分开，可以更好的维护代码，MVC 架构因此诞生。
- Model: 负责数据和业务逻辑
- View: 负责UI展示
- Controller: 作为中间人处理用户输入更新 Model，并接收 Model 数据更改事件及时更新 View
在 MVC 的模型中，数据的更改流程如下：
- 点击按钮， View 通过 Controller 向 Model 发送请求
- Model 触发了数据更新，更新了Model 中的数据
- View 收到 Model 发送的数据变更消息，更新显示内容。
MVC 的架构非常好用，但是 View 和 Model 之间直接耦合，View 可以直接读取 Model 的数据，且 Controller 无法对 View 和 Model 之间的交互进行控制。
在项目开发过程中，一个可能被滥用的功能最终一定会被滥用，因此 View 和 Model 的耦合在项目进行的过程中必然导致屎山的堆积。
在这种情况下， MVC 的改进版本，MVP 被提了出来。
MVP 和 MVC 之间最大的差异就是 View 不再持有 Model，所有的数据都交给 Presenter，也就是曾经的 Controller 进行处理。
Presenter 同时持有 View 和 Model 的引用，控制所有的交互逻辑。
- 点击按钮， View 通过 Presenter 向 Model 发送请求
- Presenter 更新 Model 中的数据
- Model 发送数据变更事件
- Presenter 收到 Model 发送的数据变更消息，更新 View 中显示的内容。
从以上的内容，我们可以看出在 Unity 的项目开发中，虽然我们经常说 MVC 架构，但实际使用中，我们用的其实是 MVP。View 层一般是 UGUI 的各种组件，Presenter 是 附加在 UGUI 组件上的 MonoBehaviour 脚本，Model 是各种各样的数据存储类。
最后，我们简单的介绍一下 MVVM。
MVVM 是 MVP 的一个变种，ViewModel 就是 MVP 中的 Presenter。MVVM 的一个改进是将 Presenter 中操纵界面元素的部分去除了，让 View 上的数据直接与 ViewModel 的数据进行绑定，省去了在 Presenter 中写更新 View 界面元素参数的代码。
在实现上，我们一般使用 UniRx 来实现数据的绑定，由于并不常用，所以在这里不做详细介绍。