MVC设计模式从代码分离的角度来考虑软件的架构和组织，最初源于SmallTalk语言，后来在GoF中有了深入的讲解；

SmallTalk时的MVC架构有如下特点：

M　　代表业务数据的来源；

P　　Presentation展现由View和Controller同时维护，缺一不可；对于每一个Model都有相对应的VC对，因此VC没有真正的分离；

C　　Controller处理用户的输入，并执行相应的业务逻辑；

O　　Observer pattern观察者模式被使用到，因为每当Model变化时，需要通知对应的VC处理；

　　  Observer pattern演化为如今的Publish/Subscribe模式；

　　"spaghetti"翻译为意大利面条，用于调侃在使用MVC框架之前写代码的方式，那种方式的特点就是：可读性差、维护性差；以前后端开发有MVC和分层的思想，可维护性好，前端仅仅只担负数据简单展现的责任；导致更多的重心集中在后端；但是时代快速变化，以Google、Facebook的新生力量希望能够胜过IBM等传统软件企业，以更好的用户体验(通过图表)来展现数据，导致前端的职责逐步扩大，因此复杂的业务逻辑参与进来，使得新的框架和开发模式快速更新。

　　回顾典型的MVC框架有如下的特点：

M　　逻辑独立，不牵涉VC，当数据变化时，以publish的方式通知每个观察者，实现与VC的分离；

V　　视图的展现通过template替换原始的字符串拼接方式；触发事件的绑定通过Controller来做的，这种方式不好，是个弊病（因为将视图关联的事绑定到了Controller，分离不现实），但确实是当前框架Backbone所能提供的，

　　  摘自：You may wonder where user-interaction comes into play here. When users click on any elements within the view, it‘s not the view‘s responsibility to know what to do next. It relies on a controller to make this decision for it. In our sample implementation, this is achieved by adding an event listener to photoEl which will delegate handling the click behaviour back to the controller, passing the model information along with it in case it‘s needed.

C　　充当MV的调停者，当V发生变化时，通过C通知M改变；当M变了时重新渲染V；

　　根据第一篇博文中的介绍，Backbone严格意义上不算MVC架构，但属于MV*家族，因为VC不分离；个人角度来考虑，Backbone框架侵入性太强，干涉了正常的执行流程，使用者很多的时间花在了内部执行逻辑上，易用不易学，易学不易变；

　　看博文中的MVP介绍，感觉文中乏善可陈，看得一头雾水，还是没有看出来C与P的区别来；可能是脑中充满了太多backbone的逻辑，所以只能个人总结一下，MVP模式从字面上看是P替代了C，实际思想上是一种进步：

　　1. MVP写出来的组件，可测试性强，可以针对组件的功能做单元测试，提高了复用性；

　　2. 外部业务对组件的使用，仅仅局限在P层面上就可以，无需关注V，基于此开发的应用摆脱了对V的关注与依赖；

　　3. 企业级软件可以利用此类基础组件做快速的开发；

　　针对前端开发来说，纯粹的MVC开发比较难，困难主要还是因为监听并处理视图的非业务性逻辑放在那里更合适，如果放在C，则VC不分离；如果放在V，V不太好实现（未听说特别成熟的此类框架）；基于Backbone实现的MVC更多的是VC混合，造成了C被V绑架了的局面（虽然V往往是固定的，不经常变）；

　　基于MVP思想的类库，如DOJO框架基础类库，使用者往往仅需关注使用哪个可以满足业务功能的组件，而不是组件怎么使用；MVP组件内部也会有属于自己的M和V，但是M与业务的M无关，因为MVP的目的是可复用，如果是MVC的话，M就固定在了某类业务M上；

参考：

1. Understanding MVC And MVP 　　　　http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/

理论篇 前端MVC、MVP、MVVM思考2