為什么要學(xué)習(xí)架構(gòu)？

不管是MVC還是MVP，亦或則其他架構(gòu)，它們的設(shè)計(jì)目的都是為了達(dá)到編碼的最高境界，那就是：低藕合，高復(fù)用，易測(cè)試，好維護(hù)。

而要達(dá)到這個(gè)終極目標(biāo)，首先要理解的是每個(gè)部分各自負(fù)責(zé)些什么，以及如何組合在一起。因此我個(gè)人認(rèn)為，學(xué)習(xí)架構(gòu)關(guān)鍵在兩步：

1. 如何把纏在一起的代碼拆分。
2. 如何把拆開的代碼再組合。

很多新手在剛做項(xiàng)目時(shí)，都會(huì)把所有的代碼，如數(shù)據(jù)的訪問(wèn)和處理，數(shù)據(jù)的展示，用戶的輸入都寫在一起，代碼和思維都呈現(xiàn)出一種線性的形式，一切都是直來(lái)直往的。這樣代碼量確實(shí)少，寫的時(shí)候也覺(jué)得方便，但是帶來(lái)了幾個(gè)致命的問(wèn)題：

1. 當(dāng)業(yè)務(wù)越來(lái)越復(fù)雜時(shí)，修改代碼成了噩夢(mèng)。同樣的邏輯放在不同的地方，本來(lái)只用改一處的變成了需要改幾百處。而又因?yàn)樗械倪壿嫸蓟ハ酄砍蹲?，?dǎo)致本來(lái)只想改一處的，結(jié)果卻影響了幾百處。
2. 當(dāng)時(shí)間越來(lái)越遙遠(yuǎn)時(shí)，理解代碼成了噩夢(mèng)。本來(lái)只需要閱讀幾行的時(shí)候，卻因?yàn)樗械拇a都雜在一起變成了要閱讀幾千行。時(shí)間一長(zhǎng)，重新閱讀時(shí)，別說(shuō)別人，就是自己也很難一下就能掌握關(guān)鍵點(diǎn)。
3. 當(dāng)需要做一個(gè)功能時(shí)，卻發(fā)現(xiàn)代碼無(wú)法復(fù)用，明明是一樣的邏輯也只能靠Ctrl＋C加Ctrl＋V。這又為今后修改代碼時(shí)增加了工作量。
4. 當(dāng)需要測(cè)試時(shí)確發(fā)現(xiàn)很難進(jìn)行測(cè)試，每次修改一處代碼后都必須進(jìn)行重復(fù)的人工測(cè)試，無(wú)法進(jìn)行自動(dòng)化測(cè)試，模塊和模塊也無(wú)法拆開來(lái)進(jìn)行獨(dú)立的單元測(cè)試，每次都要整體的測(cè)一遍才能確保一切完好如初。

要換的不是架構(gòu)，而是思維方式

其實(shí)目前市面上的架構(gòu)模式已經(jīng)有很多種，各有不同，但模式終究只是一種設(shè)計(jì)理念的表現(xiàn)形式，學(xué)習(xí)再多的架構(gòu)，你也只是多會(huì)用了幾種工具而已，學(xué)習(xí)一種模式其實(shí)是在學(xué)一種思維方式：

如何在解決問(wèn)題的時(shí)候把問(wèn)題合理的拆分，又如何將拆分的零件合理的組裝成解決問(wèn)題的工具。

將這種思維方式深入到你的大腦里，血液里，直至骨髓，讓它成為你思考問(wèn)題的一種習(xí)慣和定式，逐漸成為你的一部分，那么這時(shí)你已達(dá)到無(wú)招勝有招的境界了。

閑話先不扯了，回正題。

實(shí)現(xiàn)架構(gòu)沒(méi)有唯一標(biāo)準(zhǔn)

這里首先需要說(shuō)明的是無(wú)論MVP或MVC還是MVVM等任何一種架構(gòu)和模式其實(shí)都沒(méi)有誰(shuí)優(yōu)誰(shuí)劣之分，而且就算是同一種架構(gòu)，也可以根據(jù)不同的使用場(chǎng)景來(lái)做不同的實(shí)現(xiàn)方式，這里并沒(méi)有宇宙絕對(duì)的對(duì)錯(cuò)標(biāo)準(zhǔn)和概念定義。這和張三豐在教無(wú)忌太極拳以后讓其先忘掉招式是一樣的道理，在應(yīng)用型領(lǐng)域，定式和概念只應(yīng)是在學(xué)習(xí)的過(guò)程中才存在的，而真正學(xué)會(huì)以后應(yīng)該馬上忘掉定式，忘掉概念，將其用熟用活才是關(guān)鍵。

所以說(shuō)我在此描述的概念也不是唯一的標(biāo)準(zhǔn)，而只是個(gè)人對(duì)其的理解。

什么是MVC

因?yàn)镸VP是MVC的一個(gè)變種，因此我們先來(lái)看在MVC里代碼是如何拆分和組合的，這里簡(jiǎn)要的描述常見(jiàn)的定義：

1. 拆分：Model負(fù)責(zé)數(shù)據(jù)，View負(fù)責(zé)顯示，Controller負(fù)責(zé)用戶輸入。
2. 組合：View將用戶操作和事件傳遞給Controller，Controller將用戶命令翻譯成消息來(lái)傳遞給Model，Model在處理完數(shù)據(jù)后，通知View來(lái)顯示給用戶，而View又從Model取出數(shù)據(jù)。

我認(rèn)為在學(xué)習(xí)MVP之前，必須深刻理解什么叫做MVC，因?yàn)閮烧叩膮^(qū)別其實(shí)沒(méi)有你想象中的那么大，與其神話并盲目追崇新的架構(gòu)，期望其能解脫你于苦海，還不如深刻的理解MVC的設(shè)計(jì)理念，這就和學(xué)習(xí)一門新語(yǔ)言一樣，只有你真正深刻的理解了其思維方式，那么學(xué)習(xí)新的一門語(yǔ)言其實(shí)都是易如反掌的。因?yàn)樗鼈兤鋵?shí)都是在做一件事，只是做的過(guò)程上有些許差異而已。

更多MVC的理解，可以參考我之前寫的一篇文章：在談MVP之前，你真的懂MVC嗎？

什么是MVP

MVP與MVC最大的區(qū)別就在與將Model和View通過(guò)Presenter隔開了，不再允許其互相直接通信，而所有的消息都是通過(guò)Presenter這個(gè)中間人來(lái)傳遞。

而這樣做的目的主要是為了將數(shù)據(jù)和展示劃出更明確的界限。

首先我們來(lái)看MVP到底是在解決什么問(wèn)題的：

• 數(shù)據(jù)管理
  1. 什么是數(shù)據(jù)？(Model)
  2. 如何篩選數(shù)據(jù)？(Selections)
  3. 如何改變數(shù)據(jù)？(Commands)
• 用戶界面
  1. 如何展示數(shù)據(jù)？(View)
  2. 如何通過(guò)事件來(lái)改變數(shù)據(jù)？(Interactor)
  3. 如何將這些放在一起？(Presenter)

可以看出其實(shí)一個(gè)GUI程序的核心，還是在于用戶和數(shù)據(jù)之間的關(guān)系。而架構(gòu)的引入也是為了解決這幾個(gè)核心的問(wèn)題。

那么MVP又是如何解決這幾個(gè)問(wèn)題的，Model，View，Presenter三者又各自負(fù)責(zé)什么呢？誰(shuí)來(lái)負(fù)責(zé)請(qǐng)求網(wǎng)絡(luò)數(shù)據(jù)，訪問(wèn)和存儲(chǔ)本地?cái)?shù)據(jù)，誰(shuí)來(lái)負(fù)責(zé)處理數(shù)據(jù)，誰(shuí)來(lái)負(fù)責(zé)顯示數(shù)據(jù)，誰(shuí)又來(lái)負(fù)責(zé)和用戶交互呢？

具體表現(xiàn)在代碼上，也可以說(shuō)：網(wǎng)絡(luò)請(qǐng)求應(yīng)該放在哪，數(shù)據(jù)庫(kù)訪問(wèn)應(yīng)該放在哪，業(yè)務(wù)邏輯應(yīng)該放在哪里，處理用戶輸入應(yīng)該放在哪，誰(shuí)又來(lái)控制顯示或隱藏View的等具體的細(xì)節(jié)問(wèn)題。

帶著這些具體問(wèn)題，我們一起來(lái)學(xué)習(xí)。

如何拆分

首先來(lái)看MVP各自負(fù)責(zé)什么：

1. Model，負(fù)責(zé)定義數(shù)據(jù)（解決什么是數(shù)據(jù)）
2. Presenter, 負(fù)責(zé)在Model和View之間，從model里取出數(shù)據(jù)，格式化后在View上展示（解決如何把數(shù)據(jù)和用戶界面放在一起）。
3. View，負(fù)責(zé)擔(dān)任一個(gè)被動(dòng)界面，用于展示數(shù)據(jù)。（解決如何展示數(shù)據(jù)）

和MVC比較而已，這里出現(xiàn)一個(gè)最大的疑問(wèn)就是：那么誰(shuí)來(lái)負(fù)責(zé)和用戶的操作交互呢？答案是，用戶在View上的所有操作（事件）都由View路由給Presenter，由Presenter來(lái)與其交互。

而和MVC最大的區(qū)別在于Model和View完全被Presenter隔開了，Presenter作為它們之間的中間人去傳遞所有數(shù)據(jù)。

如何組合

三者又是如何組合起來(lái)的呢？

很顯然Presenter作為中間者，它是同時(shí)擁有View和Model的引用的，為了在它們之間起到橋梁作用，即Presenter會(huì)主動(dòng)和View和Model進(jìn)行通信。

而Model和View必須是完全隔離的，不允許兩者之間互相通信，保持對(duì)彼此的不感知，這樣的好處是你徹底將數(shù)據(jù)和展示分離來(lái)開，并且可以獨(dú)立的為Model去做測(cè)試。

Model在三者中是獨(dú)立性最高的，Model不應(yīng)該擁有對(duì)View的引用，而且Model也不需要保存對(duì)Presenter的引用，對(duì)于Presenter而已，Model只需要提供接口，等著Presenter來(lái)調(diào)用時(shí)返回相應(yīng)數(shù)據(jù)即可，這和經(jīng)典MVC模式中是非常不同的，在MVC中Model在數(shù)據(jù)發(fā)送變化后，是需要發(fā)送廣播來(lái)告之View去更新用戶界面的，而在MVP中，Model是不應(yīng)該去通知View，而是通知Presenter來(lái)間接的更新View的。

而Presenter和Model的關(guān)系也應(yīng)該是基于接口來(lái)通信，這樣才能把Model和Presenter的耦合度也降到最低，那么在需要改變Model內(nèi)部實(shí)現(xiàn)，甚至徹底替換Model的時(shí)候，Presenter則是無(wú)需隨之改變的。這樣做帶來(lái)的另一個(gè)好處就是你可以通過(guò)Mock一個(gè)Model來(lái)對(duì)Presenter以及View做模擬測(cè)試了，從而提高了可測(cè)試性。

那么View和Presenter的關(guān)系呢？View是需要擁有對(duì)Presenter的引用，但僅僅是為了將用戶的操作和事件立即傳遞給Presenter，為了讓View和Presenter耦合較低，View也只應(yīng)該通過(guò)接口與Presenter通信，從而保證View是完全被動(dòng)的，一方面它由用戶的操作觸發(fā)來(lái)和Presenter通信，另一方面它完全受Presenter控制，唯一需要做的事情就是如何展示數(shù)據(jù)。

簡(jiǎn)要總結(jié)三者之間的關(guān)系是：View和Model之間沒(méi)有聯(lián)系，View通過(guò)接口向Presenter來(lái)傳遞用戶操作，Model不主動(dòng)和Presenter聯(lián)系，被動(dòng)的等著Presenter來(lái)調(diào)用其接口，Presenter通過(guò)接口和View/Model來(lái)聯(lián)系。

View <- 接口 <- Presenter ->接口 -> Model

View -> 接口 -> Presenter <- 接口 <- Model

Talk is cheap, show me the code

為了便于理解，這里提供一些偽代碼加注釋演示一下如何實(shí)現(xiàn)MVP模式：

View

interface IUserView {
  
  void setPresenter(presenter);
  void showUsers(users);
  void showDeleteUserComplete();
  void showDeleteUserError();
  
}

class UserView implements IUserView {

  UserPresenter presenter;
  
  // 保持對(duì)Presenter的引用，用于路由用戶操作
  void setPresenter(presenter) {
      this.presenter = presenter;
  }
  
  // 將Presenter傳遞來(lái)的數(shù)據(jù)展示出來(lái)
  void showUsers(users) {
      draw(users);
  }
  
  // Model操作數(shù)據(jù)成功后，通過(guò)Presenter來(lái)告之View需要更新用戶界面
  void showDeleteUserComplete() {
      alert("Delete User Complete");
  }
  
  // Model操作數(shù)據(jù)失敗后，也是通過(guò)Presenter來(lái)告之View需要更新用戶界面
  void showDeleteUserError() {
      alert("Delete User Fail");
  }
  
  // 當(dāng)用戶點(diǎn)擊某個(gè)按鈕時(shí)，將用戶操作路由給presenter，由presenter去處理
  void onDeleteButtonClicked(event) {
      presenter.deleteUser(event);
  }
  
}

Model

interface IUserModel {
  
  List<User> getUsers();
  boolean deleteUserById();

}

class UserModel implements IUserModel {
  
  // 在數(shù)據(jù)庫(kù)里查找數(shù)據(jù)，并將數(shù)據(jù)返回給presenter
  List<User> getUsers() {
    return getUsersInDatabase(id);
  }
  
  // 在數(shù)據(jù)庫(kù)里刪除數(shù)據(jù)，并將結(jié)果返回給presenter
  User deleteUserById(id) {
    return deleteUserByIdInDatabase(id);
  }
  
}

Presenter

interface IUserUserPresenter {
  
  void deleteUser(event);

}

class UserUserPresenter implements IUserPresenter {
  
  // 保持對(duì)View的引用
  IUserView view;
  // 保持對(duì)Model的引用
  IUserModel model;
  
  UserUserPresenter(IUserView view, IUserModel model) {
    this.view = view;    
    this.model = model;
    
    this.view.setPresenter(this);   
  }
  
  void start() {
    // 從Model中取出數(shù)據(jù)
    List<User> users = model.getUsers();
    // 將數(shù)據(jù)發(fā)送給View，讓其展示到用戶界面
    view.showUsers(users);
  }
  
  void deleteUser(event) {
    // View將用戶操作路由過(guò)來(lái)，由Presenter來(lái)處理
    long uid = whichUserNeedToDeleteBy(event);
    // 將用戶操作翻譯成命令或消息傳遞給model，以改變數(shù)據(jù)
    boolean success = model.deleteUserById(uid);
    // 將Model操作數(shù)據(jù)后的結(jié)果通知View來(lái)改變用戶界面
    if (success) {
        view.onDeleteUserSuccess();
    } else {
        view.onDeleteUserFail();  
    }
  }
}

OK，到此一個(gè)最簡(jiǎn)單的MVP模式就實(shí)現(xiàn)了，可以看到整個(gè)架構(gòu)的輪廓已經(jīng)很清晰了，而且面向接口編程也帶來(lái)了很多的好處，讓代碼之間藕和較少，對(duì)測(cè)試支持也更為友好，理解和維護(hù)起來(lái)也更加方便了。

以后有時(shí)間再為大家描述如何在android里面實(shí)現(xiàn)MVP模式，以便更具體的理解。有疑問(wèn)歡迎參與討論，大家一起學(xué)習(xí)進(jìn)步。

參考文檔

1. Model–view–presenter WIKI
2. MVP: Model-View-PresenterThe Taligent Programming Model for C++ and Java