By

前面介绍了MVC，MVP两种架构模式，使用MVC开发中Android应用的时候，Activity、Fragment相当于控制层, 布局视图归于视图层, 数据库等数据模型相当于数据层。
这种方式一般控制层不仅仅只是处理业务逻辑，还负责View的展示等，并且数据层和视图层是有交互的，不利于解耦。
而MVP则是使用Presenter层将数据层和视图层完全隔离开来，比如下图作为例子：
(图来自http://tech.vg.no/2015/07/17/android-databinding-goodbye-presenter-hello-viewmodel/)
视图层与用户交互的时候用户请求loadUser命令，这时候视图层并不直接处理这个任务，而是将其传递给Presenter层，紧接着，presenter层，将showLoading请求发送到View层，并请求
数据层从数据库中获取用户信息，通常情况下数据层也会通过设置回调的方式持有Presenter引用，在Presenter接收到数据加载结束的时候，请求View层调用showUsers方法，显示用户信息。
整个结构十分清晰，但是它有个很大问题就是会照成Presenter层会变得十分庞大，并且Presenter层类会变得繁多。

下图是上面例子用MVVM替代后的架构图，在用户发送请求的时候，View会将事件发送给ViewModule，ViewModel从Module层获取数据，在数据获取完后只要改变Bean对象ViewModule就可以直接将数据呈现在View上。
整个结构的核心层是ViewModule层，在Android开发中我们使用的是DataBinding机制来实现这层：这样的好处显而易见，整个框架少了更新View的逻辑，也就是少了MVP模式中的showXXXX方法。只要数据一变视图层就立刻改变类了。

[Reference]

blog.csdn.net/jdsjlzx/article/details/51174396
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0603/2992.html
https://www.aswifter.com/2015/07/11/android-data-binding-example/
http://www.tuicool.com/articles/7Zz6J3r
http://www.zhihu.com/question/30976423
http://tech.vg.no/2015/07/17/android-databinding-goodbye-presenter-hello-viewmodel/
http://blog.csdn.net/fancylovejava/article/details/50821616
http://www.zhihu.com/question/33538477?sort=created
http://hannesdorfmann.com/categories/
http://hannesdorfmann.com/android/mosby
http://hannesdorfmann.com/mosby/first-app/
http://hannesdorfmann.com/android/mosby-playbook
https://github.com/konmik/nucleus
https://github.com/square/mortar
https://github.com/inloop/AndroidViewModel
https://github.com/Nilzor/mvp-to-mvvm-transition

Contents