本文内容提要：
记录自己在公司Android客户端项目中MVP架构的使用经历。及对其的衍生的感悟。
架构示意图.gif
涉及知识点：
阅读时间：
5分钟
为什么使用MVP：
如题，在MVP还没出来前，Android开发架构基本属于一个无序状态。所有的逻辑、视图、逻辑处理等处理都在一个Activity/Fragment中。在业务快速迭代中，这样的开发模式会导致代码越来越冗长，维护与扩展难度越来越大。举个例子，在公司的项目中，未重构前的商品详情页就多大4000行代码。
MVP的好处之一就是能将视图层，数据层，逻辑层解耦。维护成本与扩展性就自然而然的解决了。同时，MVP的架构最大的好处就是能执行单元测试。不是说传统的开发模式不能进行单元测试。而是其组织架构不够整洁。单元测试既混着视图，又有逻辑。而基于MVP的开发，能够让对逻辑层单独进行JUnit+Mockito，而视图层可以使用Espresso、Robolectric进行单元测试。
MVP实践路线：
- 一开始，我的MVP是针对View、Presenter、Data都写一个接口。这样开发下来，发现了这样下会增加许多接口。接口过多也不是一个好的设计。
- 后来受到了Google Todo MVP 的影响。将三层接口都整合到了Contact中
- 这一阶段，我针对所有的数据传输，使用的是EventBus。因为涉及到多个View需要监听同一个数据返回。本来想写一个专门APT框架于这种情况的Bus框架。不过后来思考之后，开始让View之间通过接口的形式相互传递数据比较合适。
- DTO（Data Transfer Object）与VO（View Object）。一开始，MVP各层间的传输使用的是DTO。可是如果字段变了，又需要修改三个文件。因此引入了VO可以将修改降低到最少。
- 其实网上还有许多MVP的变种，比如把Activity变为P层等。这些单从立意上，我就不是很赞成。因而作罢。
感悟与总结：
MVP本质上是面对接口编程的一种实现而已。不需要把它的太重。而是不是所有业务都要用mvp呢？一开始我是固执的认为需要的。想想所有的代码都能那么干净单纯是会有多棒啊！可是渐渐的，我体会到这“过分的设计”的下场。首先，我写的MVP，对不懂MVP的同事来看，是不好维护的。其次，在简单场景下使用，用mvp 反而增加了它的复杂度。某种意义上，是很不好维护的。
我意识到了过度设计的困扰。不过，我反而感到庆幸。让我及早领悟这个道理。
