MVC、MVP、MVVM的理解

MVC
M->Model，主要功能是数据请求等业务处理；
V->View，Activity和Fragment；
C->Controller，核心业务层，也在Activity和Fragment中；

传统的开发模式，优点是文件小，主要写一个xml布局文件和Activity/Fragmeng控制层以及一个网络请求封装工具类就可以了，但这就会导致一个十分严重的问题，代码臃肿，因为所有的核心业务，实现逻辑都在Controller层，因此一些业务复杂的页面，Activity/Fragment的代码上几百行甚至几千行，后期维护成本非常高；另外，Model和View层也有关联（数据请求回来后渲染数据到页面），这就导致了三者之间的耦合度非常高，不利于后面的人开发和维护，代码的可读性也低。

MVP
M->Model，主要功能是数据请求等业务处理；
V->View，Activity和Fragment；
P->Presenter，View和Model的桥梁，封装数据的请求方法和将请求返回的数据处理成View需要的格式；

MVP开发模式的本质是通过Presenter这个角色处理Model和View之间的关系，降低了一层耦合，有以下几个特点：
1、Model只负责业务数据的请求，这和MVC是一样的，View只负责渲染数据，但Model和View之间没有任何的交集；
2、Presenter就负责数据的逻辑处理，View和Presenter也是没有直接关联的，而是通过定义好的接口进行交互的，其实现逻辑如下：在View层中，有一个Presenter成员变量，同时View需要实现一个接口，这样可以将View层中需要的业务逻辑操作通过Presenter成员接口转交给Presenter来实现，进而Presenter通过Model得到相应的数据，并通过View层实现的接口返回到View中。这样View层和Model层的耦合就解除了，同时也将业务逻辑从View中抽离出来，转移到Presenter中，避免了Activity或Fragment过度臃肿，充斥大量业务逻辑代码；
3、Model层只是单纯的数据请求业务，可以用于多个View;
4、MVP各个角色都有自己的工作，且工作明确，耦合度低，易于管理，方便测试，但是有一个比较突出的缺点，MVP中的Presenter和View使用的接口的方式连接两层，如果逻辑复杂的页面，接口会很多，会导致维护接口的成本大。

MVVM
M->Model，主要功能是数据请求等业务处理；
V->View，Activity和Fragment；
VM->ViewModel，实现Presenter的功能，但他和View之间是被观察者和观察者的关系；

MVVM和MVP的最大区别是ViewModel和View之间不再是通过接口实现交互，而是被观察者和观察者的关系，其功能如下：
1、View触发事件后，会通知ViewModel进行数据请求；
2、Model数据拿到后，ViewModel会通过LiveData通知View进行更新；
3、谷歌发布的DataBinding可以实现ViewModel数据直接渲染到xml中；