Android Design Pattern Test（2）

继续之前的工作~现在进入MVP的篇章！

MVP结构

MVP1

原文链接
MPV 是从经典的MVC模式演变过来的，其基本思路都是相通的。其中M是model模型，提供业务数据；P和MVC中的C担当的角色相似，是Presenter控制者，进行逻辑处理。V是View视图，显示数据。
MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。
之前的Demo里我们发现在MVC模式里，Activity既负责Controller又负责View，同时Activity可以通过Model获取数据。而在MVP模式中，View与Model完全分离，大大减少了Activity的职责，最大的好处就是Activity文件不会再出现上千行的情况了。

结构

在此Demo里，Model层保持不变，依旧通过网络获取数据，对外通过接口返回数据。Activity扮演View层的角色，负责界面的显示。同时实现Presenter进行中间的控制。
Presenter表示器同时持有 Model和View对象且实现了OnPhoneMsgListener接口取回Model模型数据，因此，PresenterImpl向Model发送数据请求，然后通过OnPhoneMsgListener接口实现获取请求结果，再将结果通过接口PhoneMsgView把数据显示到Activity担当的View视图中。

总结

• MVP框架模式完全将Model模型和View视图分离，从而使得代码的耦合性第，利用MVP框架写项目达到解耦作用。
• 通过这种写法的MVP，每个Activity/Fragment都需要根据自身的需求实现一个Presenter，这不免带来了代码量的增加，但是也带了结构清晰，测试方便，便于协同等等的好处。有一些团队甚至可以在业务确定，UI未定的情况下，使用MVP模式先实现Model层和Presenter层的代码。
• 问题：由于Activity/Fragment本身有着复杂的生命周期，而在不同生命周期可能会触发不同的事件，这也给这种写法MVP模式带来了一定的问题。我会在之后的时间里探究其他的MVP实现方式。
  补充：当然可以在Presenter中定义onResume()/onDestroy()等方法实现对生命周期事件的处理。

Github地址:https://github.com/zhangke445566/AndroidDesignPatternTest