关于MVC, MVP, MVVM三者的区别，参考的信息来自以下：
1. <<Learning Javascript Design Patters>> http://addyosmani.com/resources/essentialjsdesignpatterns/book/
2. WIKI: MVP http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter
3. WIKI: MVVM http://en.wikipedia.org/wiki/Model_View_ViewModel
4. 从MVC在前端开发中的局限性谈起 http://www.infoq.com/cn/articles/starting-from-limitations-of-mvc-in-front-end-development
基于JAVA EE平台的后端MVC中，通常使用Struts或者Srping MVC框架来实现MVC，Modal代表数据库层面的原始数据，View代表展现层面的视图元素，一个项目下若干个的大功能通过不同的URL映射进行分解；
后端中的Controller从承担职责的角度来考虑分为两类：
1. 基于Router的路由：将项目的很多块功能分解；
2. 某一大功能下数据的展现：根据前端操作命令和相应的业务逻辑来展现；
前端MVC不同于后端MVC的地方在于：
1. 功能多少不一致：
后端MVC从Modal层拿到数据后，进行渲染，返回一个全新的视图页面；
前端在拿到数据后，在基于不刷新的情况下需要将原来的旧视图清除，渲染新数据，因此会有操作视图的逻辑；目的是为了最佳的用户体验，包括的逻辑有：
0. 分析并查找与该操作相关的DOM节点模块，针对每一个模块执行如下操作：
1. 根据业务逻辑，更改已存在的DOM节点；如：document.createElement, hide, show, etc. (较为原始)
2. 加载视图模板 (以下步骤的效果：相对简洁、统一)
3. 根据模板生成视图代码
4. 将代码append到DOM树中
5. 为节点节点绑定DOM事件
（以上典型的案例有：操作、刷新列表）
现在已经有很多的模板引擎（Underscore、Handler、EJS、JADE）可以完成渲染的操作，替代来原始的通过零散地编辑|添加DOM节点操作，这一思想可以说是借鉴于后端MVC的视图渲染；
虽然模板渲染方式不错，但依然没有解决以下两个问题：
1. controller与view牢牢绑定，无法解耦：因为获取数据逻辑、业务逻辑、渲染视图逻辑在一块；
2. 事件需要绑定的问题，在复杂的业务逻辑中，仍需在JS中完成绑定的工作依然不可避免。
MVP（Presenter）的出现，着重为了解决两个问题：
1. 解耦和：view与presenter分离，view上的按钮操作，会触发Presenter中一个方法，该方法无参数无返回，但是Presenter会得到该view的数据，并更新view。
2. 可测试性：通过自动化的单元测试来确保业务逻辑的正确性；
由此看来，基于MVP的思想可以产生很多可以复用的组件，DOJO的dijit中的每一个类都封装好了属性、方法，使用者仅仅只需要调用方法即可完成，无需操作DOM；每个类中Presenter是这个类本身的JS逻辑，View是这个类对应的DOM template。所以基于DOJO开发的项目可以很好的达到以上两个目的：解耦、组件可测试。
以下一段话转自MVP WIKI：
The degree of logic permitted in the view varies among different implementations. At one extreme, the view is entirely passive, forwarding all interaction operations to the presenter. In this formulation, when a user triggers an event method of the view, it does nothing but invoke a method of the presenter that has no parameters and no return value. The presenter then retrieves data from the view through methods defined by the view interface. Finally, the presenter operates on the model and updates the view with the results of the operation. Other versions of model-view-presenter allow some latitude with respect to which class handles a particular interaction, event, or command. This is often more suitable for web-based architectures, where the view, which executes on a client‘s browser, may be the best place to handle a particular interaction or command.
MVP思想不错，可是一个项目的开发往往需要很多不同的组件，许多时候组件MVP化的时候，减缓了项目的开发进度，极端时更多的精力在于开发新的业务组件、维护组件稳定性、扩展性；在追求快速、轻量级、需求不断迭代更新的项目中，这一方式不够理想。
基于MVP思想的DOJO框架，个人感觉有点OOP化，同时也过于重量级；
MVVM思想出自于MS的WPF（Windows Presentation Foundation）和Sliverlight，前端框架的典型体现是：Angular；它的典型特点是（案例：过滤查询列表）：
1. 分离页面渲染逻辑（页面中嵌入for|if根据数据来呈现）与业务逻辑（从后台拿到数据后的处理），两者分离；
2. 双向的数据绑定 视图层不再被动，通过（框架内部实现的自动的）监听 数据的变更来动态更新视图；
以下转子WIKI MVVM:
MVVM facilitates a clear separation of the development of the graphical user interface (either as markup language or GUI code) from the development of the business logic or back end logic known as the model (also known as the data model to distinguish it from the view model).
Angular中的VM的M通过Controller来获取并持有数据、V通过Controller在页面的ng标签语法来表示页面逻辑；同时业务逻辑可以通过$service来完成；所以AngularJS可以完成如下的功能：
1. 事件绑定页面化，不再混入JS中，避免掺杂页面逻辑；
2. router、controller、service角色相当明确，代码可维护性非常强；错误很容易定位，一旦出现bug，就很容易找到属于那个角色，并找到代码根源；
3. 可测试性，TDD的测试可以专门测试前端业务逻辑，在以后的web开发中，前端不再是一个简单的展现层，可以将后台更多的业务逻辑放到前台，减少与Server的交互成本；
总结各自的特点：
0. 原始方式：
缺点：
页面中保存数据，
JS的代码逻辑混合：一个方法中既有对数据的获取操作、又有业务操作、还有页面渲染操作、最后事件绑定、append到DOM树；
错误不易被定位：出错处难找、代码需要通篇阅读一边、复杂的逻辑需要断点跟踪多次；
1. MVC
优点：
分离数据、视图；
控制器介于MV之间，充当调停者、观察者；
缺点：
控制器层面的逻辑（基于Backbone实现的TODOMVC）跳转过多；
需要事件绑定；
2. MVP
优点：
Presenter将视图抽象，封装出相应的方法，OOP化；
功能细化，可拆解性强，形成一系列组件的组合使用；
组件可测试化；
缺点：
MVP需要组件化，导致项目开发速度相对缓慢；
到最后不知道该维护的是项目？还是可复用的组件；
3. MVVM
优点：
分层思想明确，代码不会混淆；
view <--> view modal <--> controller（充当modal） <--> service <--> router
页面渲染逻辑独立；
事件绑定独立；
可测试性更强：业务逻辑独立，更为专注，以后可以扩展更多的后端逻辑与前台，以减少交互，
模板引擎：
Underscore http://underscorejs.org/#template
Moustache http://mustache.github.io/
EJS https://github.com/tj/ejs
JADE https://github.com/jadejs/jade