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中的代码，就变得简洁多了，便于我们后期对代码的维护。
微信公众号：
如有不足之处，请多多指教。