Android MVP 理解

Model-view-presenter (MVP)是使用者界面设计模式的一种

Model 定义使用者界面所需要被显示的资料模型，一个模型包含着相关的业务逻辑。

View 视图为呈现使用者界面的终端，用以表现来自 Model 的资料，和使用者命令路由再经过 Presenter 对事件处理后的资料。

Presenter 包含着元件的事件处理，负责检索 Model 取得资料，和将取得的资料经过格式转换与 View 进行沟通。

Model----数据存储

对于一个结构化的App来说，Model角色主要是提供数据的存取功能，Presenter需要通过Model层存储，获取数据，简单的说，Model就是封装了数据库DAO或者网络获取数据的角色，或者两者方式都有的集合。
就是类似JavaBean，实体类，这里数据逻辑要处理的事是LoginInteractor，即是登录操作，LoginInteractorImpl则是其具体实现，由LoginInteractorImpl获取数据操作，获得Model，就是登录获取的数据，即是JavaBean实体类，数据模型。

View----用户界面

View通常指的是Activity,Fragment或者某个View控件，它含有一个一个Presenter成员变量。通常View需要实现一个逻辑接口，将View上的操作转给Presenter进行实现，最后Presenter调用View逻辑接口将结果返回给View元素。
界面显示，这里LoginView表示了界面应该有的反应，如登录成功的反应，登录失败的反应。要显示在界面上。

Presenter—交互中间人

Presenter主要作为沟通View和Model的桥梁，他从Model层获取数据后，返回给View层，使得View和Model之间没有耦合，也将业务逻辑从View角色上抽离出来
中间人，管理UI逻辑和数据逻辑的实现，但是怎么实现其不用考虑。它只负责两者的结合。这里LoginPresenter是中间人要做的事，而LoginPresenterImpl是其具体操作实现。这里管理登录操作和界面登录结果显示。

mvp模式的优点
解除View与Model的耦合性，带来良好的可扩展性、测试性。
降低耦合度，实现了Model和View真正的完全分离。
模块职责划分明显，层次清晰。
Presenter可以复用，一个Presenter可以用于多个View，而不需要更改Presenter的逻辑（当然是在View的改动不影响业务逻辑的前提下）。

mvp模式的缺点
与mvc模式一样，对于小规模项目，反而会带来更多的工作量以及复杂性。
额外的代码复杂度及学习成本。

总结
MVP三者之间的关系是：View和Model之间没有联系，View通过接口与Presenter进行交互，Model不主动和Presenter联系，被动的等着Presenter来调用其接口，Presenter通过接口和View/Model来联系

以上纯属于个人理解