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····