mvp架構解析

MVP如今已是目前最火的架構，不少的框架都是以MVP爲基礎，甚至於Google本身都出一個MVP的開源架構。https://github.com/googlesamples/android-architecture，裏面有好幾個項目，咱們先談下todo-mvp這個最基礎的MVP架構。

說到MVP，咱們不得不談到最最經典的MVC架構。什麼是MVC，歸納來講就是數據層，控制層以及顯示層的分離。雖然咱們能夠把全部的代碼都寫在一個類裏，可是做爲了一個優秀的程序員你我想必定不會這樣作，因此咱們想到了解耦，解耦也是擴展性，可測性以及可維護性的基礎。那麼最簡單也最通用的解耦就是分層，根據調用關係從上而下或是根據業務的特性，從業務功能分層實現。如jsp+severlet+db的mvc結構就是按照從上到下劃分的。Jsp是用於顯示，serverlet是業務控制，db是數據層。MVC的層級結構以下：

Controller響應用戶的操做事件，以及對請求事件的轉發和處理。在事件的處理和轉發過程當中會操做Model，對Model進行必要的增，刪，改，查等一系列單一或是組合處理。而Model是在通過Controller的操做後，讓View根據Model刷新本身的狀態，從而呈現給用戶，可是Model是不能直接通知View的，必定要經過Controller 。這個是一個完整的MVC流程。簡易交互以下：

而在android裏對應的mvc結構是：V能夠理解爲控件，C是activity，M是數據。 若是M的變化要通知到V，只能走： M->C->V,這條路徑也就是上圖的體現，這比較經常使用的，但這種交互有個缺點，就是會致使C很複雜：C做爲Activity要進行業務邏輯處理，要控制V的現實邏輯，同時還要作好告知V數據變化的任務。這樣會致使一個角色具備多種功能，這在架構中是很很差的一種表現方式，會使得這個模塊代碼行數多，邏輯複雜，不可測，擴展性差等問題。

爲了使得C的功能儘可能單一化，因此咱們就引入了MVP模式（我的見解），這個P是什麼，能夠把P當作是一個三角菱鏡，放在了上面的交互中間，因此MVP的交互能夠當作： 

圖中紅色部分就爲P.藍色爲原來MVC的調用路線，黑色爲MVP的調用路線。經過P的引入，會最大化的釋放C的功能，使得C功能單一化，把業務邏輯處理和告知V數據變化等功能分離給P來處理。這樣C的功能更多的是初始化P,V,M三則之間的關係。

咱們來分析下todo-mvp(咱們只是從架構層次去分析，不是從業務或是代碼邏輯分析)：下面是todo-mvp一個功能addedittask的UML圖（用的是Gliffy畫的，不是很標準），其餘功能相似

 

每一個功能都包含一個Activity,一個或是多個fragment，以及對應的Presenter在這個MVP模式中，Activity已經不是MVP的一部分了，它更多的做用是全局控制，初始化這個三者之間的關係。如何初始化的呢？是經過

new AddEditTaskPresenter(
        taskId,
   Injection.provideTasksRepository(getApplicationContext()),
        addEditTaskFragment);

這行代碼，新建一個TaskPresenter，同時傳入一個TaskRepository和Fragment，進行關聯的。

全部界面顯示的都放在了Fragment裏，Frament實現了TaskContract裏的View接口，View接口定義了一些顯示操做，具體是何時顯示確實由Presenter來決定，由於Presenter實現全部的業務邏輯。Model層爲了可擴展性，也經過接口的形式來實現。

每一個功能都包含一個Activity,一個或是多個fragment，以及對應的Presenter在這個MVP模式中，Activity已經不是MVP的一部分了，它更多的做用是全局控制，初始化這個三者之間的關係。如何初始化的呢？是經過

new AddEditTaskPresenter(
taskId,
Injection.provideTasksRepository(getApplicationContext()),
addEditTaskFragment);

這行代碼，新建一個TaskPresenter，同時傳入一個TaskRepository和Fragment，進行關聯的。

全部界面顯示的都放在了Fragment裏，Frament實現了TaskContract裏的View接口，View接口定義了一些顯示操做，具體是何時顯示確實由Presenter來決定，由於Presenter實現全部的業務邏輯。Model層爲了可擴展性，也經過接口的形式來實現。

這就是整個MVP的框架，這樣的一個好處是：極大的簡化了Activity的功能，同時引入了Presenter，把業務邏輯和Model的入口都放在Presenter。有人擔憂這樣會致使Presenter過於龐大，對於這點我說下個人觀點：Presenter不是一個類，徹底能夠根據業務須要引入多個Presenter。