感觉反而 还复杂一点，关系并不纯粹，游戏里用的少...的确 是知道为什么游戏不用了

理解思想就可以了，实际操作也是动态的分析，硬套某种模式也不是怎么很合适

MVC的了解应该是差不多了，重点还是实际中的使用了

所以删了会自动置空

置空问题

也不一定要，这里只是强调而已

在一个物体（假设是物体A）上挂载了脚本S，并且在另一个物体的脚本中引用了物体A上的脚本S，那么当你销毁物体A时

如果你尝试在物体 A 销毁后访问引用的脚本 S，Unity 会给你一个 空引用异常（NullReferenceException），因为你仍然保持对一个已经被销毁的脚本的引用。

在构造函数里赋值也可以

如果换成别的Panel，要改的地方

也就是说这里的通知是通知要显示面板出来，然后再给通知的body加上具体要显示的面板名字字符串

具体的操作是在定义的Command类里面执行的

这个body省略的是同一类型的效果实现，一直创建新的不同的Command类继承SimpleCommand

重点是这里的面向对象思想很深，Proxy和mediator都是作为单个的类，反而有点像是在java里面

facade这三个都可以注册

但这些继承了SimpleCommand的类要在Facade总管里面初始化Command和notfication之间的联系...等等，也许这里才是为什么Controller为什么也是一个大圈的原因...

这里也算是一本大字典的对应了，但依然没有实际的物理练习

继承了simpleCommand之后，这个类里面写mediator和Proxy之间相互传递的指令

Controller不会有实实在在的和command的联系，就是一个抽象概念，想要把所有的command的归类出一个整体感和保留对mvc的延伸的感觉，这个图就留了Controller这么一个大圈

文档太规范工整，想快速了解一下反而比较困难

可选的增加的方法

mediator和Proxy到时都是需要在facade里面注册使用的

目前为止都是在单独个体上的定义

大多数的参数都是用object来装载，自己使用的时候，as回要调控的类

不写ListNotificationInterests和HandleNotification

mediator就没有用了

HandleNotification接收的通知信息，是接受到了上面添加的要关注的通知字符串

当某些事件被触发之后，就会发出通知，而通知的名字如果在这个mediator的关注范围之内

就会把触发该通知的事件相关联的各种数据相结合

对Proxy的构造操作就是图中这条连接线的构建

对于数据的持久化问题，这里因为可以在定义代理的时候把数据一条一条的赋值，然后存好

其实在外部统一拿个什么函数把data赋值完毕，然后再调用这里的Proxy构造函数，这样其实会更直观一点

但两种办法都可以，我直接帅气

在构造函数内实例化一个对象然后再赋值

这个小细节的确很微妙，看上去没什么用，但这一点点，可以增加很多该类型数据的实例化方式

这样

数据可以为null但一定要有名字

代理的名字和代理的数据，构成代理类的父类构造函数

代理的名字非常重要，Model相当于大字典，代理往里面存的话一定要有名字的

 

public class ApplicationFacade : Facade
{public void Startup(){// 初始化 Model、View、ControllerInitializeModel();InitializeView();InitializeController();// 注册一些初始的 Proxies、Mediators、CommandsRegisterProxy(new UserProxy());RegisterMediator(new UserViewMediator());RegisterCommand("FETCH_USER", () => new FetchUserCommand());}
}

在 PureMVC 中，Model、View 和 Controller 各自可能会有多个代理（Proxies）、中介者（Mediators）和命令（Commands）。在应用程序的启动函数中，可以通过调用初始化方法（例如 InitializeController、InitializeModel 等）将所有依赖关系注册完成，这使得启动流程逻辑清晰且易于维护。

虽然可以省略启动函数，并在应用的其他部分手动进行注册，但这可能会导致初始化代码分散，降低代码的可维护性，也会增加出错的几率。

靠，写的真看不了，太生硬了

Command 可以调用多个 Proxy执行事务处理，当事务结束后，发送Notification

不要在那些生命周期长的对象（long-living object）里引用Command对象

Controller大大 实例化一个 该 Notification 对应的 Command

并且将 Notification 作为参数传递给 execute 方法。

这个文档写的，真的是没人性味

Command 对象是无状态的；只有在需要的时候（Controller 收到相应的 Notification）才会被创建

Controller 会注册侦听每一个 Notification，当被通知到时，Controller 会实例化一个 该 Notification 对应的 Command 类的对象。最后，将 Notification 作为参数传递给 execute 方法。

Facade 和 Proxy 只能发送Notification，Mediators 既可以发送也可以接 收Notification

提供一个带有应用程序类型参数的 startup 方法，该参数能过 Notification 传递到 StartupCommand。

Notification（通知）发出时相关的 Command

Façade类是整个系统其他角色相互 访问通信的核心，

所以在这里定义 Notification（通知）名称常量 

ApplicationFacade 继承自 PureMVC 的 Façade 类，Façade 类实现了IFacade接口。

Command注册所有的Model和View。

建立Command与Notification名之间的映射

对View层和Controller层的改变不应该影响到Model层。

Proxy需要发送Notification（通知），比如：Proxy从远程服 务接收到数据时，发送 Notification 告诉系统

同名的 Notification（通知）时，关心这个通知的 Mediator 都会调用handleNotification 方法并将 Notification 以参数传递

View 注册 Mediator 时，Mediator 的 listNotifications 方法会被调用， 以数组形式返回该Mediator对象所关心的所有Notification。

Mediator发送、声明、接收Notification

Notification可以被用来触发Command的执行

只需要使用一个非常简单的方法从 Proxy, Mediator, Command 和 Facade 发送 Notification，甚至不需要创建一个 Notification 实例。

可以不用关心PureMVC的Observer/Notification 机制是怎么实现的，它 已经在框架内部实现了

Controller 保存所有 Command 的映射。Command 类是无状态的，只在需 要时才被创建。

Command 可以获取 Proxy 对象并与之交互，发送 Notification，执行其他 的Command。经常用于复杂的或系统范围的操作，如应用程序的“启动”和 “关闭”。应用程序的业务逻辑应该在这里实现。

需继承Façade 类创建一个具体的Façade 类就 可以实现整个 MVC 模式

Proxy、Mediator 和 Command 就可以通过创建的 Façade 类来相互访问通 信。

MVC的细化

虽然的确是对MVC想做什么有了解了，但是深入下去，我写代码的能力不一定站得住脚

也许应该去官网看看文档了