MVC VS MVP VS MVVM

在MVC的模式中，代表Model-View-Controll，实现了功能的划分

但是在Android早起的MVC中，Activity 起了controller的作用，在 controller中直接操作model，然后实现view的刷新

这种会导致controller的结构相对来说臃肿一些

 

不同于MVC, MVP中，将Activity/Fragment这些都看作是View层，Presenter 成为了View和Model沟通的桥梁，

因为在MVP的涉及中，Presenter和View层充分发挥了 面向接口编程的特性，实现了View和Model的解耦 

由Presenter来实现和View,Model之间的双向交互

MVP的缺点：

1 页面复杂度过高时，可能会导致Presener过大 （解决方法：将大的Presenter划分为一个个功能单一的小Presenter）

2 页面过于复杂时，View层需要实现的接口过多

3 Presenter本身是对生命周期无感的，需要手动去进行敢于，如果使用RxJava中的LifeCycle，或者通过Fragment/Activity的LifeCycle 将Presenter注册，这样能够监听Activity/Fragment的生命周期

4 业务过于复杂时，需要ViewModel 可能会过于膨胀，此时需要将一个ViewModel分解为多个小ViewModel

 

鉴于MVP中存在的一些问题，MVVM 提供了一些解决方案

LiveData的特点：

1 实现对生命周期的感知，

2 对model发生变化，主动通知Observer去刷新View，（相比MVP，省略了一些接口的实现）

MVVM的缺点：

在RecyclerView的使用中，如果不进行oldData 和 newData的比较，是不能进使用高效刷新的，如notifyItemInserted(),notifyIteemChanged();

如果存在下拉刷新，加载更多，网络出错时的重拾操作等， 这些时机在刷新View层需要不同的 刷新方式，

WrappedLiveData extends MutableLiveData

{

class Response {

 int state; //代表不同的状态：成功（加载更多成功，下拉刷新成功，网络出错重拾成功），出错（下拉刷新出错，加载更多的出错，重试操作出错）

List data;

}

}

在ViewModel层面，需要根据State去组装不同的Response,然后需要在监听到数据变化时，通过state的状态来执行不同的刷新策略 

对于上面场景，个人觉得使用MVP可能更好一些，在 Presenter层定义不同的数据请求接口，在 View层定义各个场景下的刷新策略接口，在Presenter 层通过不同的State来执行View层的不同刷新策略