https://github.com/livoras/blog/issues/11
MVC
调用关系如下：
Controller(model) ，controller中执行业务逻辑，操作model
View(controller,model)，view中绑定dom的交互事件，回调函数中调用controller的方法；接着对model进行监视，设置对应的回调方法（model.on(xx,()=>{ 此处更新dom })）
Model()，当自身数据被修改时，自身发出对应事件（this.trigger(xx)）。
特点：代码的执行次序依次 View -> Controller -> Model -> View
优点：
1.模块分化明显，易于管理。Controller集中了业务逻辑、View集中了dom操作
缺点：
1.单元测试困难。测试controller，修改了model，view中事件回调修改dom，被修改的视图难以检测正确性
2.混乱的数据流（多个model与多个view交错调用）。即由于 Model 对外直接暴露了 set 和 on 方法，导致 View 层可以随意改变Model中的值，也可以随意监听 Model中值的变化。这样的设定最终会导致一个庞大的 Model中某个字段变化后，可能触发无数个 change 事件，在这些 change 事件的回调中，可能还有新的 set方法调用，导致更多的 change 事件触发，更糟糕的是，一个 Model 还能改变另一个 Model 的值，整个数据流动的方式变得更加混乱，不可捉摸（这里参考自《深入React技术栈》P193中对MVC的解释，感觉和本文对MVC的解释不一致，model的set方法本在本文应该是在controller中调用，而不是给view直接调用的）
3.页面更新逻辑复杂（多个局部更新导致页面整体逻辑复杂）。一个页面中有多个view，都有自己独立的渲染操作，支持独立更新，这种独立更新正是高效率的关键（当前页面的状态是由多个view的更新界面函数所决定的），但会导致整个页面的更新逻辑复杂，难以定位问题
对于2、3点的解决方案：把多个局部更新替换一个整体更新，及每次更新数据，就读取所有数据，重新渲染整个页面，这导致效率低下，但数据流动清晰，逻辑简单。
以上过程中，trigger和on的观察者api可以这么实现：
<script src="http://libs.baidu.com/jquery/2.0.0/jquery.min.js"></script>
<script>
// 方式1：使用jquery
var model = $({});
model.on('xx',function(evt,val){
console.log('xx happened ' + val)
});
model.trigger('xx',1);
// 方式2：自定义
function Model(){
var evts = {};
this.on = function(evtName,cb){
evts[evtName] = evts[evtName] || [];
evts[evtName].push(cb);
};
this.trigger = function(evtName){
var cbs = evts[evtName] || [];
var evt = {};
var vals = [evt];
vals = vals.concat([].splice.call(arguments,1));
cbs.forEach(function(cb){
cb.apply(null,vals)
})
}
}
model = new Model();
model.on('xx',function(evt,val){
console.log('xx happened ' + val)
});
model.trigger('xx',1);
// 方式3：使用node EventEmitter
</script>
MVP
和mvc的区别在于，对model的监听和更新dom（model.on(xx,()=>{ 更新dom })） 从view中移动到presenter。
调用关系如下：
View(presenter)，绑定dom交互事件，调用presenter中的业务逻辑，设置对外的更新ui的接口
Presenter(view,model)，执行业务逻辑，更新model，在model的监听事件中，调用view的接口，来修改view
Model()，和mvc一致
特点：代码的执行次序依次是 view -> presenter -> model -> presenter -> view
优点：
易于测试。把对model的监听和更新dom的操作移动到了presenter中，测试的时候仅仅需要关注presenter中的逻辑即可，因为对于view，这里仅仅是调用了那一块的接口，所以不需要对那边担心。
view便于组件化。写好对外的更新ui的接口，以及在交互事件中调用presenter即可。
MVVM
是对mvp的改良。
MVVM的调用关系和MVP一样。但是，在ViewModel（Model of View）当中会有一个叫Binder，或者是Data-binding engine的东西。以前全部由Presenter负责的View和Model之间数据同步操作交由给Binder处理。
ViewModel = Presenter + Binder
在界面（或者是view的模板里）中声明好view与model的绑定关系，binder去读取这个关系，并做好记录，内部完成双向绑定的功能。即Presenter中对model进行修改，Binder自动去修改对应的ui，ui上发生变化（input输入），Binder自动把数据更新到model上。