今天我为大家带来的是MVP的开发套路，帮助大家认识MVP，喜欢MVP。

MVP是什么？

MVP设计模式

view（客户），presenter（产品狗），model（程序猿）。

有一天，客户找到了产品狗说：“我要开发一个像微信一样的App”

然后，产品狗原封不动地转达了给程序猿，程序猿默默地说了一句：“傻X，有病”。

当然产品狗也不会这么傻，它当然要在客户面前夸他，于是在电话里头说：“我们的工作人员，对此表示有挑战性，但是他们很乐意。”

于是新需求就来了，最终苦逼的还是程序猿。

终于，程序猿受不了了，辞职了，但是又来了一批新的，需求还是需求，并不会因为人不同了，就推掉这单生意（重构项目）。

view（客户），contorler（产品狗），model（程序猿）

有一天，客户找到了产品狗和程序猿说：“我要开发一个像微信一样的App”

程序猿默默地说了一句：“傻X，有病”。

嗯，打起来了，项目没了。

通过这么深刻的故事，我们看到了MVP的优点

1、view和model相互不认识（解耦），并不会因为model不一样了，而影响了view，反过来也一样。那么model什么时候会变呢？例如，老子原来用的是Volley网络框架，但是我现在要换成OKhttp。没关系，我只需改动model即可。

2、model是面向接口文档编程的，view是面向设计图编程的，而presenter是负责协调的，这样就可以并行开发了。

3、测试，因为是view和model不认识（解耦），那么就可以单独地对model进行测试，验证它的准确性。做好了view，真机调试，又可以发朋友圈了。最后用presenter连起来，如果测试得好，Bug也会少很多。

4、做不好不用背锅，还可以多踩一脚（O(∩_∩)O~）。我做model的，数据给你了，你显示那么丑......这是一个后台跟App的故事。

5、presenter（产品狗），可以同时面对多个view（客户），做更多的事情（累死更多的程序猿）。

MVP的缺点

1、presenter负责逻辑，代码会多。（产品狗确实挺累的）

2、写得很累，明明view跟model可以直接相连，非要跟presenter联系，可能在传递时出现Bug。（明明程序猿可以跟客户面对面沟通，但是经过了产品狗，回来的需求就不一样了）

3、我还要想。（直接下个主题）

MVP开发攻略套路

model层

model开发一条龙

这是我开发的套路，希望你们喜欢。正常情况下，3天就能完成所有的接口文档对应的model。而在做model的时候，面对的是接口文档，没有比这个东西更接近需求了，因此，你做完之后会更加明白这个项目。

用Rxjava+Retrofit是什么体验

直接生成Bean对象

view层

view开发一条龙

简单但是暴力。我还有隆重地为大家推荐几款插件。

1、SelectorChapek for Android（自动生成Selector的XML文件），再也不要考虑那些乱七八糟的press，focus，normal

2、jimu Mirror（不需要写代码，就能在真机显示布局，包括列表），神器！加快了朕发朋友圈的速度。

3、butterknife（依赖注入库，自动注解布局中带@+id的控件），用完就更model的同学说，真慢！

4、Android studio自带的Get，Set生成器。

presenter层

Sept1

根据model的所需参数创建外部调用接口（presenter的方法接口）

Sept2

实现Sept1中的接口和model层提供的回调接口

Sept3

根据业务逻辑，调用view层提供的方法。

小结

由于model和view可以同时进行开发，提高了开发效率，减少了bug。

在外部调用方法中加上适当的注释，可以让我更好地沟通。

总结

我前段时间做了一个ASP.NET mvc5的网站，虽然mvc5很清晰，但是在逐渐开发的过程中，model和view渐渐勾搭上了，到最后分不开了，我们也没办法。导致了项目重构的困难，最后的命运是重做。

我最近一段时间用MVP做了一个App，由于我对MVP的理解不到位，导致了代码很大部分的冗余，有一些没有必要提供外部调用的方法，我却硬要追求MVP模式的套路，结果导致了代码很乱，跟大家的忠告是，MVP是一个工程，不是一种硬性的规则，我们灵活一点。

我最近几天，做了一个看图的App，我发现MVP模式上用上封装和继承，会让我们的代码更加的好看。而且复用率大大提高。

文章来源：简书，作者：帅气小伙，原文：http://www.jianshu.com/p/1223b6fde7f1