标签:io sp on 数据 bs 代码 ad as new
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会导致要创建很多的类,代码的职权并没有明确划分,个人感觉有些鸡肋。
标签:io sp on 数据 bs 代码 ad as new
原文地址:http://www.cnblogs.com/tianlanliao/p/4165393.html