上个月参加了敏捷之旅成都站的活动，其中有一个朋友分享了“提升软件研发领导力的招式和模式”，模式用通俗一点的说法就是“套路”，他介绍了模式（套路）在我们生活和工作中的积极作用，“模式并不是一项新发明，而是一个被记录和证实的最佳实践或者一个解决方案，而且在特定环境下，模式是可以复制的”，包括我们常听到的设计模式其实也是这样。
一个人善于使用模式，相当于把一些特定问题进行了抽象概括，大脑其实可以腾出更大的空间处理别的事情（具体的业务等）。所以，这一两年我也比较喜欢尝试使用一些流行的模式或者开源框架到自己的项目中，最终不一定会投入使用，但尝试的过程还是很有益处的。
今天就来和大家谈一谈最近一两年在Android开发中比较火的模式：MVP & MVVM。
面试题：谈谈MVP和MVVM模式，你有在自己的项目中使用过吗？
好吧，其实问过很多面试者，结果说明MVP和MVVM模式并没有到妇孺皆知的境地。不过也好，这么一个简单的问题我们就可以很容易区分出面试者是否对Android开发有热情。
在解释MVP时，我们往往喜欢拿它和大众都比较熟悉的MVC进行比较。
MVC全名是Model--View--Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。其中Model层处理数据，业务逻辑等；View层处理界面的显示结果；Controller层起到桥梁的作用，来控制View层和Model层通信以此来达到分离视图显示和业务逻辑层。
我们往往把Android中界面部分的实现也理解为采用了MVC框架，常常把Activity理解为MVC模式中的Controller。
而MVP其实是MVC的一种演进版本，它更简单，将MVC中的Controller改为了Presenter，View通过接口与Presenter进行交互，降低耦合，方便进行单元测试。
View：负责绘制UI元素、与用户进行交互(Activity、View、Fragment都可以做为View层)；
Model：对数据的操作、对网络等的操作，和业务相关的逻辑处理；
Presenter：作为View与Model交互的中间纽带，处理与用户交互的逻辑。可以把Presenter理解为一个中间层的角色，它接受Model层的数据，并且处理之后传递给View层，还需要处理View层的用户交互等操作。
我们看看如下的MVC和MVP的对比图更能直观的理解这两种模式的区别：
最明显的区别就是，MVC中是允许Model和View进行交互的，而MVP中很明显，Model与View之间的交互由Presenter完成。
那么我们为什么需要MVP或者其他模式呢？现实中，我们常遇到一些不使用架构的项目（程序员都很任性，功能需求到哪里代码就写到哪里），需求中的一个页面对应项目中的一个activity或一个fragment，所有的界面响应代码、业务逻辑代码、数据请求代码等等都集中在其中，一个类的代码非常臃肿难于理解和维护。
如何在自己的项目中使用MVP
官方给我们写了一些MVP的样例工程，用不同的概念和工具实现同一个Todo项目。
- todo-mvp/ - mvp基础架构示例。
- todo-mvp-loaders/ - 基于mvp基础架构项目，获取数据部分使用了Loaders架构。
- todo-databinding/ - 基于mvp基础架构项目，使用了数据绑定组件。
- todo-mvp-clean/ - 基于mvp基础架构项目，使用了clean架构的概念。
- todo-mvp-dagger/ - 基于mvp基础架构项目，使用了dagger2进行依赖注入。
- todo-mvp-contentproviders/ - 基于todo-mvp-loaders架构项目，使用了Content Providers
- todo-mvp-rxjava/ - 基于mvp基础架构项目，全名用RxJava进行并发和数据层处理。
虽然在官方推出这套MVP开源用例之前，网络上也有很多优秀的开源项目教大家如何使用MVP模式，如果你之前没看过，其实现在还有一个好处，直接按官方的来做就是了（官方一出马，其他的类似项目就哑火了）。我看了一下官方的todo-mvp确实比之前自己实现的要简单明了一些，而且测试用例也写得比较完整可以直观体验一下MVP在这方面的好处。
MVP的好处与问题
当你了解清楚MVP模式后，它的好处也就很明显了：
- UI层和逻辑层分离，UI层不在涉及业务逻辑代码，某层的改动不需要到处去修改代码；
- 测试很方便，你可以直接调用Presenter层写测试用式（可以使用Junit框架）；
- 最后是可维护性和可扩展性，MVP的各个类职责都非常明确且单一，后期的扩展，维护都会更加容易。
当然，坏处也很明显，首先代码类增加了，一个小功能你可能要为它专门写Presenter和Model层的实现，以前这些你一口气就加在View层了。同时需要对新进项目的人员进行一些MVP模式的培训，以便他们不会写出破坏已有模式的代码。
MVVM模式
MVVM模式（Model--View--ViewModel模式），和MVP模式相比，MVVM 模式用ViewModel替换了Presenter ，其他层基本上与 MVP 模式一致，ViewModel可以理解成是View的数据模型和Presenter的合体。
MVVM采用双向绑定（data-binding）：View的变动，自动反映在ViewModel，反之亦然，这种模式实际上是框架替应用开发者做了一些工作（相当于ViewModel类是由库帮我们生成的），开发者只需要较少的代码就能实现比较复杂的交互。这一步对于我还是比较有吸引力了，可以少写很多模板代码。
官方在Google I/O 2015大会上推出来MVVM模式的支持函数库Data Binding Library。在Android Studio 2.1 Preview 3之后，开始支持双向数据绑定，即在View层修改输入也会触发Model层的改变。
当然，做过WinPhone开发的人一定想起来了微软在很多年前就在使用MVVM模式了。
小结
再次说明，你的项目并不一定非要用MVP/MVVM或者别的什么模式，模式都有它们自身应用的场景，有好处也就会有坏处。但了解是必需的，不然你很难扩展自己的技能范围，高级的开发应该学会判断某个项目是否合适一些现成的模式，合理的使用模式会让你的应用框架更加清晰并且易于维护和扩展。
