MVP模式的理解

        MVP分为Model，View，Presenter分别对应模型层(实体模型，业务逻辑)，视图层(activity，fragment)，P层(连接模型层与视图层，控制交互)

• 模型层除去bean对象外定义业务逻辑接口，生成业务逻辑实例，主要根据需要处理的逻辑生成接口，eg：在一个登录页面，模型层的接口拥有login()方法。在一个数据库读取操作，接口就拥有readDB()。

• 这点需要与下一点对应起来看，不然不好理解。一般一个P对应一个View，P层里持有一个ViewInterface实例(一般由对应的View里传入)，并持有一个模型层的业务逻辑接口实例(一般在构造方法里自行初始化)，用于连接二者，然后生成所需要的方法，eg：在一个登录的Demo中，LoginPresenter持有一个LoginViewImpl，里面有一个loginSuccess()方法用于显示登录成功的Toast，LoginPresenter还持有LoginModel的实例，里面有一个login方法，View里持有LoginPresenter的实例，里面有一个login方法。(建议这段多看两次)，在View里有一个Button，点击进行登录，在点击操作后，View调用LoginPresenter的login方法，LoginPresenter的login方法里调用LoginModel里的login方法，在登录成功后再调用LoginViewImpl的loginSuccess方法，由此便完成了一次交互。

• 一个View需要对应一个ViewInterface，ViewInterface里面定义的是View里需要操作的与界面相关的接口方法。eg：清空EditText，showDialog，showToast，so on...，然后用对应的View去实现这个对应的接口。View里需要持有对应的Presenter，用于交互时的逻辑处理，详细可见上一点的例子。

        至此就是一个简单的MVP模式实施过程。

       可能会不理解，一个简单的登录操作定义这么多的接口，这么多的类是不是有点画蛇添足，对于小型的项目来说确实是，但优点也是显而易见的，View里就只负责显示数据和与用户的交互，与用户交互的逻辑又交给Presenter来调度，最后由Model来执行，这样就把View与业务逻辑完全的解耦开了。原来的项目是不是在一个Activity里做了很多事，既要处理业务逻辑，还要与用户交互，还要显示，太过于臃肿，耦合度也很高。采用MVP模式后就很清晰了，View就只管显示与交互，Presenter来进行对应的调度，Model来完成逻辑处理，代码也清晰了。

    

      还有一个很重要的优点是方便进行单元测试，以前的项目是不是感觉进行单元测试无从下手，必须要运行一次项目，然后模拟用户的操作来测试，大家知道运行一次是很费时间的，与单元测试的初衷有悖，采用MVP模式后，我们就可以模拟一个View，模拟它与用户的交互，来验证Presenter里的方法是否正常工作，提升了可测试行。

本篇介绍得太过主观化，你们可能看着费劲，不知道我在说什么，推荐一篇文章。让你们更清晰的理解MVP

 

http://blog.csdn.net/lmj623565791/article/details/46596109