UI框架使用QFrameWork。
Model层用来处理数据，View用来处理显示逻辑，而Controller层则是负责Model和View之间的交互，View层获取用户输入然后通过交互逻辑修改Model层数据，Model层数据发生修改之后通过表现逻辑更新View层显示，因此Controller负责了两种职责，导致随着需求增加逻辑也会变得臃肿，因此我们可以引入Command命令模式来解决。
新建两个Command脚本，用来处理Controller的交互逻辑。
然后再交互逻辑代码处调用即可：
但是当我们处理一次用户的交互逻辑之后，相对应的我们就需要刷新一次界面，也就是调用一次表现逻辑，因此我们需要引入一个事件机制来解决这个问题。
我们可以直接在Command中实现这个功能，当Command中触发数据变更之后，我们就可以发送一次数据变更事件，然后在Controller里去监听这个事件。
在Controller调用：
然后流程就会变成这样，实现了CQRS原则：
存储功能，实现在Model层上：
通过将count修改为结构体属性，然后通过PlayerPrefs存储，但是这样会有一个问题就是存储数据变多的时候，Model层代码会变得非常冗余，或者以后不想使用PlayerPrefs时，会造成大量修改工作量，因此我们可以实现一个Utility层。
然后在Architercture实现注册：
如果我们需要实现一个成就类，可以利用system来实现：
BindableProperty是包含数据+数据变更事件的一个对象，使用起来十分简单，可以替换上文的Count，并且用自带的事件替换system中的事件。
接口，所有的模块注册，代码获取都通过接口完成，这一点符合SOLID原则中的依赖倒置原则。比如想把储存的API从PlayerPrefs切换成EasySave，那我们就不需要去修改Storage对象，而是扩展一个IStorage接口即可：
注册的时候直接注册新的对象：
Query是和Command对应的查询对象，有时候可能需要大量查询、组合查询（多个Model一起查询），查询的数据可能还需要转换，因此使用Query可以解决，例如有两个model分别是StudentModel和TeacherModel：
层级规则：
表现层：ViewController层。IController接口，负责接收输入和状态变化时的表现，一般情况下，MonoBehaviour均为表现层。
○可以获取System、Model
○可以发送Command、Query
○可以监听Event
系统层：System层。ISystem接口，帮助IController承担一部分逻辑，在多个表现层共享的逻辑，比如计时系统、商城系统、成就系统等
○可以获取System、Model
○可以发送Event
○可以监听Event
数据层：Model层。IModel接口，负责数据的定义、数据的增删查该方法的提供
○可以获取Utility
○可以发送Event
工具层：Utility层。IUtility接口，负责提供基础设施，比如存储方法、序列化方法、网络连接方法、蓝牙方法、SDK、框架继承等。啥都干不了，可以集成第三方库，或者封装API。
Command：命令，负责数据的增删改。
○可以获取System、Model
○可以发送Event、Command
Query：查询，负责数据的查询
○可以获取System、Model
○可以发送Query