1.前言

   近些年来，Android架构模式有很多，我们比较熟知的有MVC，MVP以及MVVM，目前Android市场中使用最多的应该是MVP架构，虽然MVVM结合DataBing看似更加方便，但在一般公司中使用的还是比较少。其实模式这种东西就像我们个人习惯，觉得代码怎么放置会更方便，慢慢的就形成了一种标准化的模式，好的代码模式更容易后期维护与团队分工合作，但是其实说句心里话，刚接触这些模式的时候，感觉代码的类变多了，但是从逻辑上着实简洁了很多。建议还是稳中求实，不要为了架构而架构。

2.MVP和MVC相比

    毋庸置疑的是，每种模式架构都有自己的优缺点，在这里借用弘扬大神的两句话

• View：对应于布局文件
• Model：业务逻辑和实体模型
• Controllor：对应于Activity

看起来的确像那么回事，但是细细的想想这个View对应于布局文件，其实能做的事情特别少，实际上关于该布局文件中的数据绑定的操作，事件处理的代码都在Activity中，造成了Activity既像View又像Controller（当然了Data-Binder的出现，可能会让View更像View吧）。

而MVP的出现，是的view层不能和Model层直接交互，Presenter作为中间的桥梁，连接view和model，将view和model完全解耦，使得Activity代码不再臃肿。

3.以请求服务端登录为例

   学习过很多前辈的文章，讲解mvc模式时，基本都是使用登录为例，但是几乎都是使用本地数据模拟，所以相信很多人都有同一个疑问，网络请求部分的代码到底交给谁来做，Model？还是Presenter？呢。用户登录时，对于View层我们要定义View层的接口，也就是activity（或fragment,一下统称activity）的状态有哪些变化，

  首先，用户点击登录要获取用户输入的用户名和密码，弹出正在登录，从服务端返回信息，toast弹出，dialog关闭，所以我们需要定义view层的这五种状态接口。

对于Model层，需要有用户登录的方法，传入用户名和密码（map），和回调接口。

该例子中使用的是自己封装的Volley框架，封装如下：（稍候会有源码给出）

activity请求登录时，直接通过Presenter操作，所以我们Presenter实现方法中有login方法，直接调用view层的接口和model的接口去实现。

而在view层，也就是对应的activity中只需要继承view层的接口，通过Presenter去操作其中的方法即可。

这样，实现一个网络请求判断用户登录，在view中的代码，就变得简洁多了，便于我们后期对代码的维护。

微信公众号：

如有不足之处，请多多指教。