Android -- 思考 -- 为什么要在项目中使用MVP模式

1，其实有时候一直在找借口不去思考这个问题，总是以赶项目为由，没有很认真的思考这个问题，为什么我们要在项目中使用MVP模式，自己也用MVP也已经做了两个项目，而且在网上也看了不少的文章，但是感觉在高层次的思想上还是没有去理解它，都是泛泛而谈的“解耦”、“扩展”的字眼，作为一个初中级开发者，我需要的是在实际开发场景中去一一对比一下，让开发者通过比较出来的优点来选择MVP模式，那么下面就带着大家来简单的分析分析。

2，现在有这样的一个需求场景，用户点击按钮从网络上获取数据，展示到我们的TextView上面，功能很简单，我们正常使用MVC的话就是在布局文件里面添加TextView和Button控件，再在Activity中写网络请求并将得到的数据通过逻辑设置到控件TextView上去，这样就能实现我们的功能了，现在产品将我们的需求更改成，用数据库中去获取我们的数据，并把数据以Toast的形式来提醒用户，那么现在有下面两个场景

　　①、之前的版本的代码是你写的，那么现在你就要去改Activity中的逻辑，虽然麻烦，但是没事，因为之前是你写的，你知道在哪里去修改它的。

　　②、之前的版本的代码不是你写的，那么现在就有点痛苦了，你需要把逻辑重新看一遍,再重新修改之前的代码,如果逻辑一复杂,你重新看一遍逻辑要时间,如果改错的话,影响之前已经写好的功能,这完全违背开闭原则

　　那么如果我们之前就是使用的MVP模式来开发的话，我们面对现在这个新需求的话该怎么做呢？

　　首先，对于数据由接口的形式更改成从数据库中读取，那么我们只需要Model层中的数据获取逻辑，Presenter 层拿到的是 Model 的接口,只关心 Model 层返回的数据,至于你的数据是从网络还是数据库还是本地数据库文件获取的,根本不必关心。

　　进而，对于数据显示有TextView更改为Toast，由于Presenter 拿到的也是 View 的接口, Presenter 从 Model 获取完数据,返回给 View ,就完成了他的工作,他根本不用管 View 是怎么实现的,使用 TextView 显示还是 Toast 显示,这些都是 View 的事

情,所以他们每层只用把各自的事情做好根本不用管以外的事情。

　　这样我们就可以把 View , Presenter , Model 拿给三个不同的人写,需求一变不会影响整个代码,将问题最小化。UI出问题了我们就把问题定位到View层，数据出问题了我们就把问题定位到Model层。实现我们上面看到的“解耦”、“扩展”、“团队协作”的功能。

　　看了上面的内容，你对使用MVP的理由还很模糊吗？

　　See You Next Time····