MVP（理論加程式碼格式）
一、MVP概念
M : Model（資料層.負責與網路層和資料庫層的邏輯互動） （資料庫/網路請求） V : View（檢視層/UI層：負責繪製UI元素/顯示資料，與使用者進行互動，並向Presenter報告使用者行為） （activity） P : Presenter （是連線Model 和 View 的橋樑，從Model拿資料, 應用到UI層, 管理UI的狀態, 決定要顯示什麼, 響應使用者的行為）（邏輯程式碼）
二、為什麼使用MVP
之前有一個MVC模式: Model-View-Controller. MVC模式 有兩個主要的缺點: 首先, View持有Controller和Model的引用; 第二, 它沒有把對UI邏輯的操作限制在單一的類裡, 這個職能被Controller和View或者Model共享.
因為Android的特殊性，使得Activity對應了MVC中的V和C,同時擔任兩個角色，就有了類似“既當爹又當媽”的感覺，這顯然就不符合軟體設計原則的“單一職責”原則。但現實中是很多的APP程式碼中有這麼的處境，特別是Androi原生的很多系統APK，某些Activity動則幾千行程式碼。 況且，隨著專案的深入發展，很多邏輯很越來越複雜，Activity處理的東西也會越來越多，程式碼越來越臃腫。這樣一來維護起來的代價就會越來越高，這是因為View的變化會引起Controller的很多變化，反之亦然。用一句大白話來說明就是–某一段程式碼的變動會引起很多其他相關聯的程式碼的改動，而程式設計師都是懶惰的，所以會恨死這樣的程式碼。
而MVP就是要減輕在Android中的這種困惑。
MVP是基於MVC的，
三、MVP的作用
- 將檢視邏輯和業務邏輯分離開來，降低耦合度
- Activity只處理生命週期的任務
- 提高程式碼的閱讀性
- Presenter被抽象成介面，有多種具體的實現方式 業務邏輯在Presenter中，避免Activity造成記憶體洩露
- 模組職責劃分明顯
- 提高程式碼複用
- 缺點：增加了程式碼的複雜度
四、MVP的核心思想
將Activity中的檢視邏輯抽象成View介面，將業務邏輯抽象成Presenter介面
五、MVP開發在Android中的基本流程
-
View層定義View.interface，用來定義View的行為。一般由Activity或者是Fragment來實現這個介面，它定義了View檢視的各種變化，如設定Textview,載入對話方塊，更新進度條等。
-
Model層定義Modle.interface,這個是用來定義資料層發生變化時的通知介面，因為Model不能直接與View互動，所以它與Presenter互動，然後再通過Presenter間接達到與View的互動。
-
Presenter翻譯的意思是主持人，也就是主持場合，控制節奏的意思。在這時Presenter就負責具體的業務邏輯，請求資料，把資料送到Model，或者監聽Model的資料變化，接受View層的動作，負責通過通知View層的檢視變化。
六、專案架構（這裡用的是TMVP算是mvp的加強版版吧 添加了契約類/contract和更加方便）
ps：名字當然不是這樣寫的 這樣寫只是為了看起來容易理解
七、對mvp的理解
我以前在團隊工作的時候，團隊分工是每人負責相應的Activity,在這裡Activity是最小的開發單元。再後來，某些Activity變得越來越重要，越來越複雜，程式碼也越來越多，這樣會造成團隊某個人的開發任務重，而其他的團隊成員也幫不上忙。而MVP的出現可以將Activity再細分，劃為View和Presenter兩個部分，所以Activity不再是最小的開發單元，如果可以完全可以這樣分配任務，一個開發人員負責View部分，另一個開發人員負責Presenter部分。 況且因為MVP的劃分，所以各個部分其實相對獨立，V的變動會對P的部分造成較少的影響，而M對V或者說V對M幾乎是透明的。 因為Presenter的存在，View和Model就可以很輕鬆，頂多Presenter累一點。 還有一個特點是MVP模式很適合測試，單獨測試VIEW成了一種可能。我們可以模擬View和Model的資料來測試Presenter的邏輯。
未完待續