1.mediator作为ui管理器，是设计成可以list多个notification
2.所有ui想要监听notification，都需要register到facade中
3.puremvc只负责消息的方法和接受，但不负责显示列表的管理，所以对于ui，还需要自己addchild
4.INotifier发送消息，消息是原始数据。mvc内部把消息封装成Notification，进一步传递到别的模块。
5.IFacade继承自INotifier
6.controller继承自icontroller，它管理所有的command，在register一个command的时候，会在关联的view上register一个observer
7.model继承自imodel，它管理所有的proxy，在register一个proxy的时候，会调用proxy的initializeNotifier方法
8.view继承自iview，它管理所有的modiator，在register一个mdiator的时候，会调用mediator的initializeNotifier方法。
9.view在register mediator的同时，也会把mediator感兴趣的listnotification注册进observer.view也管理了一个observer列表。
10.initializeNotifier用来初始化multitonKey
11.controller model view作为manager只是继承了各自的interface，并且都有一个name，就是multitionkey
command proxy mediator作为被管理者都继承了inotifier
当proxy mediator被添加到manager的时候，manager会用自身的name(即multitionkey)初始化它们的name
12.command在每次触发的时候，都会new一个出来
13.command的执行也是通过observer的包装进行的。observer的代码是在view里的，这里单独提出来是否可以更好？
14.observer的删除也比较巧妙，比较的是消息接受的对象
15.IAsyncCommand的扩展，碰到IAsyncCommand，那么就需要等这个IAsyncCommand执行完才能执行后面的command
总结：
阅读puremvc也只是对mvc多了一层理解，只要在项目开发中遵循了mvc的思想，不一定非要采用puremvc框架。而且puremvc会导致要创建很多的类，代码的职权并没有明确划分，个人感觉有些鸡肋。