Android开发模式万佛朝中MVX（MVC、MVP、MVVM）

今天公司的测试服务器开小差了，后台被吐槽的体无完肤，虽然我们都知道跟他没有什么关系，但是生活需要乐趣，总要有人背锅，哈哈！~~~暂时没有环境开发了，那就分享一下之前做的一篇关于Android开发模式的总结，MVC，MVP，MVVM对于刚了解或者没有好好归纳总结的朋友来说，特别是那些像我记性很差的朋友来说，很容易忘记。

下面我们一起归纳总结一下，这样屡清楚他们的关系我们用起来就可以迎刃有余，也不会再面试的过程中逊色于那些背书党了。毕竟我们是属于行动派的：

不知道为何我会想起一个成语叫：万佛朝中，好吧，就用这个来做标题吧

目录

万佛朝中MVX（MVC、MVP、MVVM）

常见问题

错误一：VX层处理业务逻辑，做了M层的工作！

错误二：Model就是静态的业务逻辑数据

错误三：Model 层就是负责数据获取的

错误四：Model 层依赖 Presenter/ViewModel 层

总结：

---

万佛朝中MVX（MVC、MVP、MVVM）

MV-C

MV-P

MV-VM

实际上就是MVx（x=C,P,VM...），下面我们通过几个常见的误区来说明这些框架的原理。

常见问题

1、实际关系是：M（业务逻辑）和VX（表现层逻辑），并不是M、V、X并立的

错误一：VX层处理业务逻辑，做了M层的工作！

V层：

负责发送用户操作给X层

负责接收X层传来的控制

 

X层：

处理几乎所有的表现层逻辑。（为什么？这样方便进行单元测试）

 

M层：

Model 层包含了业务数据

以及对业务数据的操作 (behaviour and data)

 

错误二：Model就是静态的业务逻辑数据

我们做业务模块开发时，会经常定义一些数据结构，比如User类、Order类等Bean类。只有一些简单的get和set方法。有人认为这样的数据结构就是Model。一个数据结构实例没有行为，连对象都称不上，怎么能代表 Model 层呢！

静态的业务数据不能代表 Model 层，业务数据以及针对业务数据的操作共同构成了 Model 层，这也就是业务逻辑。

 

所谓的（与表现层VX逻辑区别的）业务逻辑处理就是网络请求、数据库查询等数据获取逻辑，即Model层就是负责数据获取的，这也是我要说的第三个错误观点。

 

 

错误三：Model 层就是负责数据获取的

业务逻辑层并不负责数据的获取，数据的获取职责还要在 Model 层的更下层，这也是为什么我要把的 BlogModel 的实现逻辑写得如此简单，因为数据获取的职责全部交给了 BlogFeedRepository 类，Model 层只处理业务逻辑。

BlogFeedRepository 是博客列表的仓储类，BlogModel 通过 BlogFeedRepository 的 fetch() 方法获取标签为 recommend 的博客列表，也就是推荐的博客列表。

 

 

错误四：Model 层依赖 Presenter/ViewModel 层

实际上应该是 Presenter/ViewModel 通过接口的形式依赖 Model 层，Model 层完全不依赖 Presenter/ViewModel。就像我前面的示例代码里一样，Model 层必然不会出现任何 presenter 这样的单词，上层通过观察者模式来监听 Model 层的数据变化（ LoadCallback 接口也算是一种），Model 层也不用关心上层是 Presenter 还是 ViewModel。

 

 

总结：

其实关于 MVX 还有更多可以讨论的，比如有些人认为 Model 层并不是真正处理业务逻辑的地方，它只是业务模块的一个上层封装层（下面包含真正数据获取，业务逻辑处理就是网络请求NetWorkDataReponsity、数据库查询SQLDataRepository 等数据获取逻辑），我觉得也不无道理，在复杂业务模块中，业务是存在层次的，MVX 中的 Model 层是所有业务层中的最上层。

 

还有我刚刚提到的业务层之下还有数据层，这是典型的三层架构的概念，即表现层、业务层和数据层。逻辑存在分层，所以架构也必然要进行分层，MVX 可以做为我们从代码到业务甚至到架构的探索的开端。