前言
MVC，MVP 和 MVVM都是一种整体上的架构，而不是说一种设计模式或者开发上的模式。
其都针对于一个网站的整体架构，包含前端和后端，而不是仅仅局限于前端或者后端。
一、MVC
以下引述自微软官网。
许多计算机系统的目的是从数据存储中检索数据并将其显示给用户。用户更改数据后，系统会将更新存储在数据存储中。由于信息的关键流在数据存储区和用户界面之间，因此您可能倾向于将这两部分结合在一起以减少编码量并提高应用程序性能。但是，这种看似自然的方法存在一些重大问题。一个问题是用户界面往往比数据存储系统更频繁地进行更改。将数据和用户界面片段耦合在一起的另一个问题是，业务应用程序倾向于合并远远超出数据传输范围的业务逻辑。
可能将页面中带点服务器代码会大大提升性能，但是对团队开发和维护就会造成很大对隐患，因此在早期，MVC这种结构清晰，方便维护的架构模式，就很流行了。直到现在，MVC架构仍然是主流的架构。
- V是View，视觉层，也就是用户看到的界面，常见的载体有HTML或者Jsp;
- C是Controller，控制层，可以是js代码，form的提交按钮，或者javaweb中的servlet等等，是处理逻辑;
- M是Model，有自己的行为，相应的影响会改变view的展示
MVC各自有联系，多对多的关系，图参考文章最后的参考。
二、MVP
MV和上面的MVC一样。主要是P，它是Presenter。
一般而言，Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互。并且，Veiw和Model脱耦，绝不容许直接访问Model，而是通过Presenter这个中间人。
所以，MVP一般实现方式是：通过ajax、socket使得P和M进行通信交互，然后 P 对 V 进行修改
好处：
- 因为V和M脱耦了，可以方便的单独进行测试，甚至可以单元测试，
- 和上面的差不多，模型与视图完全分离，我们可以修改视图而不影响模型
- 逻辑处理在Presenter中了，View中可以不包含逻辑处理只关心展示，各自的职责更加内聚了。
三、MVVM
该架构的后面两个VM其实表达的是一个词汇ViewModel，这是MVP的改进版。
改进在哪些地方呢？
MVP是通过代码自己实现的V改变，MVVM是自动改变。
ViewModel将Veiw中的展示数据绑定了，ViewModel相应的逻辑操作改变了自身，V也会随之改变，所以这是什么意思呢？
在国内Vue、React大行其道的今天，相信不难理解：对VM的修改会自动的影响View的渲染。（题外话：估计MVC、MVP才是近几年入职的前端开发者不懂的吧？我就是，哈哈哈）
总结
说实话，只有工作十年，见证了对互联网web技术发展的，才能有深刻的体会。随着时间的飞逝，MVC、MVP的结构都开始慢慢的被淘汰。未来是未知的，也不知当下流行的MVVM会不会有更好的替代，谁也不知道！
参考
- 阮一峰 MVC，MVP 和 MVVM 的图示
- 百度百科 MVP
- 百度百科 MVVM
- 微软 Model-View-Controller