前言
今天review MVC、MVP、MVVM模式时翻到了收藏的一篇文章，于是就准备总结一下~
原文链接
三种模式的目的
- 基于职责分离（Speration of Duties）对应用程序进行分层以求更好的管理程序。
- 展示信息跟数据的可视化界面被称作
View. - 保存数据和提供操作数据的接口被称作
Model.
暴露的问题
有了view跟model的分层同时也出现了一些问题
- 相应用户操作的业务逻辑管理（比如说排序）
- View如何响应Model数据的变更
MV*模式之间的差异主要就是对以上两个问题的处理方式的不同造成的
Smalltalk-80 MVC
在MVC模式中多了Controller这一层，其主要是为了管理应用程序的业务逻辑。
三者的调用关系
- 用户对View进行操作（如输入跟点击），View捕捉到 这个操作后将控制权交给Controller。
- Controller执行相关的业务逻辑，这些业务逻辑可能会根据Model提供的接口进行相应的读写操作。
- 当Model的数据变更后会根据
观察者模式(运用同一个Model的不同View会同时得到通知，从而同时刷新)通知View。 - View通过观察者模式收到Model变更的消息以后，会向Model请求最新的数据，然后重新更新界面。
这里有几个需要特别关注的要点
- View是把控制权交移给Controller，自己不执行业务逻辑。
- Controller执行业务逻辑并且操作Model，但不会直接操作View，可以说它是对View无知的。
- View和Model的同步消息是通过
观察者模式进行，而同步操作是由View自己请求Model的数据然后对视图进行更新。
优点
- 将业务逻辑全部分离到了Controller中，更易于管理跟日后的更新（当业务逻辑变更时只需要更换Controller，不需要更改View跟Model）。
- 观察者模式可以做到多视图同时刷新。
缺点
- Controller测试困难。
- View无法组件化。（依赖特定的Model）
MVC Model 2
这种MVC模式是在服务器端所运用的。
三者的调用关系
- 服务端接收到来自客户端的请求。
- 服务端通过路由规则把这个请求交由给特定的Controller进行处理。
- Controller执行相应的业务逻辑，对数据库数据（Model）进行操作。
- Controller用数据渲染特定的模板，返回给客户端。
因为HTTP协议是单工且无状态的，除非客户端再次发起请求，否则服务器端的Model的变更就无法告知客户端。所以这不能严格的被称为MVC模式。
MVP模式
MVP模式是MVC模式的改良（用Presenter替换了Controller）。在上个世纪90年代，IBM旗下的子公司Taligent在用C/C++开发一个叫CommonPoint的图形界面应用系统的时候提出来的。
三者调用关系
- 与
MVC模式一样，用户先对View进行操作，View将控制递交给了Presenter。 - Presenter拿到控制权后执行相应的业务逻辑对Model进行操作。
- Model数据变更后通过
观察者模式把变更消息传递给Presenter而不是View。 - Presenter获取到Model变更的消息以后，通过View提供的接口更新界面
关键点
- View不再负责同步的逻辑，而是由Presenter负责。Presenter中既有业务逻辑也有同步逻辑
- View需要提供操作界面的接口给Presenter进行调用
优点
- 业务逻辑便于测试
- View可以组件化。（View不依赖Model）
缺点
- Presenter除了要处理业务逻辑外还要处理View的同步逻辑，过于笨重。
MVVM模式
MVVM模式是对MVP模式的一种改良，将MVP中的Presenter替换成了ViewModel。
三者调用关系
关键点
View与Model通过ViewModel中的Binder实现双向绑定
- 只需要在View的模版语法当中，指令式地声明View上的显示的内容是和Model的哪一块数据绑定的。
- 当ViewModel对进行Model更新的时候，Binder会自动把数据更新到View上去。
- 当用户对View进行操作（例如表单输入），Binder也会自动把数据更新到Model上去。
- 框架的Binder自动执行了之前Presenter对View跟Model的同步逻辑
优点
- 解决了MVP需要处理大量的同步逻辑的问题。
- 简化测试
缺点
- 对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高