FairyGUI的设计目的是让美术和程序的工作独立开来，让程序专注于逻辑而让美术发挥出最大的界面效果。项目中对FairyGUI的导出加以扩展，会自动生成lua代码进行绑定，在查这部分资料时看到MVVM这个词，于是顺着又过了一遍MVC,MVP,MVVM的内容，简单作一些记录。
MVC
MVC:View-Control-Model，最早是用于桌面程序设计上，而我第一次接触到这个词则是在网页开发上。View和Model之间通过Control联系，正常逻辑从View接受输入开始，经过Control进行业务逻辑处理，改变Model状态，最后通知View更新状态给予反馈。这样视图和业务分离，使得视图需要改动时不会导致业务层逻辑也需要跟着进行重写。
但是MVC下Model数据改变后需要通知View，这导致Model中会含有View的结构。
MVP
MVP:View-Presenter-Model，为了切断View和Model之间的联系，很自然的诞生了MVP。Model更新后通过Presenter通知View更新，减少了需求变化时需要维护的对象数量。由于Presenter和View之间通过定义好的接口通信，当View变化时，Presenter甚至不用变更，可以应对频繁的需求改动。
MVC和MVP有一个很大的问题在于大量的业务逻辑都堆积在Control或是Presenter中，导致越复杂的项目到后期越难以维护。
MVVM
MVVM:View-ViewModel-Model，不再有界面接口，而是通过数据模型和数据双向绑定(观察者或是订阅等方式)，数据变动会自动反应到View上，视图上数据的变化也会直接影响数据源。这样一来使得业务逻辑和UI编写可以专注于自己的工作中，这一部分的思维就有些类似于FairyGUI的初衷了。
以上是一些很简单的总结，下面是一些结合到Unity的思考。
UI到底由谁来拼
FairyGUI致力于让程序摆脱拼UI的工作，但在目前实际工作中这部分依然是不可避免的问题。这其中最大的矛盾在于，程序拼出的界面无法还原美术原来的设计，而美术往往又没有程序的思维导致缺少层级复用的结构。作为一名程序，虽然拼UI是一件枯燥乏味的工作，但是出于下面这些原因，个人还是觉得程序还是自己扛起这个担子更合适一些。
前面就提到了，美术缺少层级结构的思想，更多的会采用平铺素材的方式，这和程序的思维是非常矛盾的。而当发现UI结构需要更改时，如果还需要通知美术并告知正确的摆放方式，其中的成本实在有点高，是不是会说这还不如我来做呢。我们在制作UI时也应该考虑资源是否可以重用，能不能抽象成一个内部模块（比如一个星级控件），大图是否可以做九宫格优化，图集是否可以合并，UI结构哪里需要独立，布局怎么适配不同分辨率，元素的锚点和缩放方式等等，而这些美术方面往往无法考虑周全。
程序的思想就是抽象和简化，在思考包括美术资源如何管理，策划配置如何填写的问题时，我们不应当仅仅把自己放在程序的位置上，而应当站到更高的高度，考虑美术和策划的习惯，这样才能更好的做出更易用的设计，做出真正高效的工具。
Unity中是否需要使用MVC等
答案自然是可以的，虽然游戏的界面与网页或是移动APP相比要复杂得多，但是MVX本身得核心思想是将视图、业务逻辑、数据进行解耦，这一点毫无疑问是通用的。而其实反观写过的项目，其实MVX的思想早就深入人心，大家都会对数据进行封装，UI也往往通过其他组件或是管理类来通信。
但是当牵涉到GamePlay的逻辑时，如果再强行套用MVX，就有些不合适了。我们要明白MVX诞生的原因和他所解决的问题，而不是什么都往模式上靠。由于一则守望先锋架构的宣讲，最近ECS被顶上了风口浪尖，而Unity也推出了ECS和Job System，之后我也会学习一下并记一些笔记。