对 MVC 和 MVP 模式的疑惑

Question

最近在看了一篇关于 MVP 的文章，挺简单的，就是介绍了什么是MVP模式。

但是对于 MVC 和 MVP 的区别真没有搞得很清楚。 看后的感觉就是「MVP 只是规范更严格的 MVC 而已」。

MVP 中的 Presenter 到底充当着一个什么角色呢？

我查了一些关于 MVP 的资料。都说 Presenter 相对于 MVC 中的 Controller 来说，还多了一个将 Model 和 View 充分剥离的作用。但是其实在我的概念里（在平时的应用中），MVC 中的 Model 和 View 是可以做到剥离的。我在平常的开发中，都会把 Model 中提供的数据在 Controller 中处理之后再渲染到页面的。也就是说，其实很多时候 MVC 已经可以做到 V 和 M 的分离了。那么，提出 MVP 模式的目的或者说要点何在呢？

希望大家能给一下自己的看法，谢谢！

Answer 1

我深信 没有不好的问题，只有不好的回答。

---

起初，只有命令行。

软件工程师的灵就运行在 shell 上。

Xerox 说：「要有 GUI」……

一、桌面软件的 MVC

感谢 Smalltalk。感谢 GUI。

二、B/S 架构的 MVC

后来，互联网兴起，于是程序员把自己的程序放到服务器上运行，此时 GUI 发生了变化。所有的界面的现实 （View层）换成了浏览器（HTML）。

此时，MVC 被带到了 BS 架构。感谢 sun。感谢 struts。

三、前端的 MVP

再后来，浏览器越来越强悍，于是很多的业务放到了浏览器里面来执行。

于是程序员们把 MVC 带到了 View 层。但是用 HTML+CSS+JS 做显示层，和传统的桌面 GUI 又有很大区别。 于是，为了充分发挥 js 语言的特点，MVP 就出现了。

Answer 2

Comparison of Architecture presentation patterns MVP(SC),MVP(PV),PM,MVVM and MVC

[翻译] MVP(SC),MVP(PV),PM,MVVM 和 MVC 表现模式架构对比

Answer 3

架构的演进：

MVC模式:
View <-> Controller <-> Model；Controller不仅负责路由，而且同时负责业务层与表现层的衔接，在开发的时候可以灵活在控制器中配置的功能。在开发时不如MVP直观，关注点也没的MVP中更简洁。

MVP模式:
View <-> Presenter（Controller <-> Events） <--> Model；Presenter隐藏了路由，控制器部分，使开发无需关心消息的路由与控制层，精力放到每个消息引发的事件中，在事件中进行业务操作。使得开发更简单直观，但是牺牲了对控制器层操作的灵活性。

MVVM模式：
View <-> ViewModel <-> Model；ViewModel不仅可以充当MVP中Presenter的功能，同时ViewModel可以主动更新View。而不是单一的由View触发后台更新。可以这么说MVVM就是MVP的增强版本