首先说明的是 puremvc 本身就有 ts 版本 而且是两个 一个 标准版本 一个是多核心 版本 ，我这里只是标准版本 这个版本 多个文件 合并成一个ts 文件而已 为的就是看起来方便 用起来 感觉是一个模块出来的而已，遵循了 cocos creator 3.0 的官方 推荐的方式，至于没有讲如何 与 cocos creator 结合 这个 后面有空了 会再讲吧，下面就是这个合并后的一个完整的 ts 文件 这样 不需要 像以前那样 用倒入插件 和 添加声明文件啥的 直接当成 t使用即可。有用的 拿去吧！
标准版合并后的ts下载地址：puremvc.ts
这个是我自己 整理后的puremvc 源码 我自己就是把多个文件 合并成一个文件 修改了几个类型的错误，其他均未曾修改，Cocos Creator 3.0 可以直接用的 本身就是ts 文件 直接使用即可
import {MsgConst} from "../../MsgConst";
import StartupCmd from "./StartupCmd";
import {Facade, IFacade} from "../../../lib/puremvc";
/**
* ApplicationFacade 类对象负责初始化Controller（控制器），建立Command与Notification 名之间的映射；
* 并执行一个Command注册所有的 Model 和View。它是PureMVC应用程序的入口。
* @author jsroads
*/
export class AppFacade extends Facade implements IFacade {
constructor() {
super()
}
public static getIns(): AppFacade {
if (!this.ins) this.ins = new AppFacade();
return <AppFacade>(this.ins);
}
/**
* 为了ApplicationFacade结构更清晰和简洁。
* 将注册Command、Proxy、View&Mediator的工作抽离到
* ControllerCommands.ts、ModelPrepCommand.ts、ViewPrepCommand.ts。
*
* 注册应用程序启动Startup命令，应用程序启动时执行 StartupCommand
* StartupCommand中将执行以下操作：
* ControllerCommand -- 初始化应用程序事件与Command之间的映射关系；
* ModelPrepCommand -- Model 初始化，初始化应用程序启动过程中需要用到的Proxy，并注册；
* ViewPrepCommand -- View 初始化，唯一创建并注册ApplicationMediator，它包含其他所有View Component并在启动时创建它们
*/
public initializeFacade(): void {
super.initializeFacade();
this.registerCmd(MsgConst.START_UP, StartupCmd);
}
/**
* 启动PureMVC，在应用程序中调用此方法，并传递应用程序本身的引用
* @param stage - PureMVC应用程序的根视图 root，包含其它所有的View Componet
*/
public startup(stage?: any): void {
this.sendMessage(MsgConst.START_UP, stage);
this.removeCmd(MsgConst.START_UP);//PureMVC初始化完成，注销STARUP命令
}
}
上面是大概的使用方法 如果之前用过肯定 看得懂的
下面说说 我对框架 对一些看法：
游戏到了一定量级和规模 比如
- 用户过5千万以上
- 日活跃三百万以上
- 前端开发人员大于5个以上(6-12个前端）
- 游戏运营准备超过半年
- 游戏准备有多个语言（国家地区，比如东南亚，阿拉伯地区）和平台（渠道）上架 且平台不同或者国家不同，需要有不同的功能或者 运营规则，但很多功能又是一摸一样。
第1个和第2个 可能在软件（游戏）上线前无法知道，但可以提前预估一个值，另外框架这事决定权在于前端主程，或项目负责人，兵熊熊一个，将熊熊一窝，大家看看大厂的很多东西都是用到框架的（一般都是自研）对于没有能力研发或者不愿意研发的公司或者团队，开源的框架将就着用吧，实在不行，自己修改嘛，比如我就是这样修改着用。
如果上面但5个里面满足2个，就要考虑框架，如果超过三个 就必须用框架（不管是自研或者是开源框架）否则一个bug 就让负责人吃不消。恰好上面的几个现象我都经历过，知道代码不规范会带来的损失，一个活动bug或者功能bug 让游戏几个小时无法正常玩，都是几十万的成本损失，老板那个脸很难看啊！若游戏开发玩没有上线运营或者运营预估不超过半年 就结束了，框架实在不太必要。另外作为技术，适当的学习一些框架和修改优化框架并用。比如经常会在框架上进行了一些改造让框架适合当前游戏。
版本更新当天晚上游戏意外发现bug，项目组几十个人等你查找问题，并修改问题，所有人站到了你的背后，经历过的会有所感受。亦或者写过事故报告分析的人，特别是因此扣过奖金的更会觉得代码规范的必要性，为了这些规范，有时候故意用框架把边城框在一个范围内。毕竟一个项目里程序员，参差不齐（为了节约成本，不会都全雇高手，一般都是老人带新人 ）
几乎所有的框架都有自己的适合场景和使用局限性以及带来的麻烦（比如上面说的臃肿），框架不能改变代码效率，但可以1模块耦合度低，2.减少成员间的对彼此模块的熟悉和掌握（比如未必每次版本更新所有人都在公司守着，以及中间有人离职有人入职，接手项目学习成本低特别是开源框架，大家综合自己的现实问题考虑就好，另外我使用框架，是便于项目管理，和移植（语言和项目移植）比如开发思想和多个项目可以共享一份成果（成熟的技术方案）多个游戏共享一份功能。
上面是我的一点点心得和体会，如果前面的几个场景没有经历过，可能不会有过深的体会到框架的重要性，当然前提游戏赚钱了才会活的长久，框架才会显示出 效果，比如 一代程序员跑路，二代程序员升职，三代程序员离职，四代程序员在维护三无祖传代码（无文档，无注释，无人知道）的难处。（游戏运行超过四年 （比如我经历的 运营了9年多）一般都会有这样的现象）
有不同看法 欢迎下面留帖交流。