為什么要學習架構？
不管是MVC還是MVP，亦或則其他架構，它們的設計目的都是為了達到編碼的最高境界，那就是：低藕合，高復用，易測試，好維護。
而要達到這個終極目標，首先要理解的是每個部分各自負責些什么，以及如何組合在一起。因此我個人認為，學習架構關鍵在兩步：
- 如何把纏在一起的代碼拆分。
- 如何把拆開的代碼再組合。
很多新手在剛做項目時，都會把所有的代碼，如數據的訪問和處理，數據的展示，用戶的輸入都寫在一起，代碼和思維都呈現出一種線性的形式，一切都是直來直往的。這樣代碼量確實少，寫的時候也覺得方便，但是帶來了幾個致命的問題：
- 當業務越來越復雜時，修改代碼成了噩夢。同樣的邏輯放在不同的地方，本來只用改一處的變成了需要改幾百處。而又因為所有的邏輯都互相牽扯住，導致本來只想改一處的，結果卻影響了幾百處。
- 當時間越來越遙遠時，理解代碼成了噩夢。本來只需要閱讀幾行的時候，卻因為所有的代碼都雜在一起變成了要閱讀幾千行。時間一長，重新閱讀時，別說別人，就是自己也很難一下就能掌握關鍵點。
- 當需要做一個功能時，卻發現代碼無法復用，明明是一樣的邏輯也只能靠
Ctrl＋C加Ctrl＋V。這又為今后修改代碼時增加了工作量。 - 當需要測試時確發現很難進行測試，每次修改一處代碼后都必須進行重復的人工測試，無法進行自動化測試，模塊和模塊也無法拆開來進行獨立的單元測試，每次都要整體的測一遍才能確保一切完好如初。
要換的不是架構，而是思維方式
其實目前市面上的架構模式已經有很多種，各有不同，但模式終究只是一種設計理念的表現形式，學習再多的架構，你也只是多會用了幾種工具而已，學習一種模式其實是在學一種思維方式：
如何在解決問題的時候把問題合理的拆分，又如何將拆分的零件合理的組裝成解決問題的工具。
將這種思維方式深入到你的大腦里，血液里，直至骨髓，讓它成為你思考問題的一種習慣和定式，逐漸成為你的一部分，那么這時你已達到無招勝有招的境界了。
閑話先不扯了，回正題。
實現架構沒有唯一標準
這里首先需要說明的是無論MVP或MVC還是MVVM等任何一種架構和模式其實都沒有誰優誰劣之分，而且就算是同一種架構，也可以根據不同的使用場景來做不同的實現方式，這里并沒有宇宙絕對的對錯標準和概念定義。這和張三豐在教無忌太極拳以后讓其先忘掉招式是一樣的道理，在應用型領域，定式和概念只應是在學習的過程中才存在的，而真正學會以后應該馬上忘掉定式，忘掉概念，將其用熟用活才是關鍵。
所以說我在此描述的概念也不是唯一的標準，而只是個人對其的理解。
什么是MVC
因為MVP是MVC的一個變種，因此我們先來看在MVC里代碼是如何拆分和組合的，這里簡要的描述常見的定義：
- 拆分：Model負責數據，View負責顯示，Controller負責用戶輸入。
- 組合：View將用戶操作和事件傳遞給Controller，Controller將用戶命令翻譯成消息來傳遞給Model，Model在處理完數據后，通知View來顯示給用戶，而View又從Model取出數據。
我認為在學習MVP之前，必須深刻理解什么叫做MVC，因為兩者的區別其實沒有你想象中的那么大，與其神話并盲目追崇新的架構，期望其能解脫你于苦海，還不如深刻的理解MVC的設計理念，這就和學習一門新語言一樣，只有你真正深刻的理解了其思維方式，那么學習新的一門語言其實都是易如反掌的。因為它們其實都是在做一件事，只是做的過程上有些許差異而已。
更多MVC的理解，可以參考我之前寫的一篇文章：在談MVP之前，你真的懂MVC嗎？
什么是MVP
MVP與MVC最大的區別就在與將Model和View通過Presenter隔開了，不再允許其互相直接通信，而所有的消息都是通過Presenter這個中間人來傳遞。
而這樣做的目的主要是為了將數據和展示劃出更明確的界限。
首先我們來看MVP到底是在解決什么問題的：
- 數據管理
- 什么是數據？(Model)
- 如何篩選數據？(Selections)
- 如何改變數據？(Commands)
- 用戶界面
- 如何展示數據？(View)
- 如何通過事件來改變數據？(Interactor)
- 如何將這些放在一起？(Presenter)
可以看出其實一個GUI程序的核心，還是在于用戶和數據之間的關系。而架構的引入也是為了解決這幾個核心的問題。
那么MVP又是如何解決這幾個問題的，Model，View，Presenter三者又各自負責什么呢？誰來負責請求網絡數據，訪問和存儲本地數據，誰來負責處理數據，誰來負責顯示數據，誰又來負責和用戶交互呢？
具體表現在代碼上，也可以說：網絡請求應該放在哪，數據庫訪問應該放在哪，業務邏輯應該放在哪里，處理用戶輸入應該放在哪，誰又來控制顯示或隱藏View的等具體的細節問題。
帶著這些具體問題，我們一起來學習。
如何拆分
首先來看MVP各自負責什么：
- Model，負責定義數據（解決什么是數據）
- Presenter, 負責在Model和View之間，從model里取出數據，格式化后在View上展示（解決如何把數據和用戶界面放在一起）。
- View，負責擔任一個被動界面，用于展示數據。（解決如何展示數據）
和MVC比較而已，這里出現一個最大的疑問就是：那么誰來負責和用戶的操作交互呢？答案是，用戶在View上的所有操作（事件）都由View路由給Presenter，由Presenter來與其交互。
而和MVC最大的區別在于Model和View完全被Presenter隔開了，Presenter作為它們之間的中間人去傳遞所有數據。
如何組合
三者又是如何組合起來的呢？
很顯然Presenter作為中間者，它是同時擁有View和Model的引用的，為了在它們之間起到橋梁作用，即Presenter會主動和View和Model進行通信。
而Model和View必須是完全隔離的，不允許兩者之間互相通信，保持對彼此的不感知，這樣的好處是你徹底將數據和展示分離來開，并且可以獨立的為Model去做測試。
Model在三者中是獨立性最高的，Model不應該擁有對View的引用，而且Model也不需要保存對Presenter的引用，對于Presenter而已，Model只需要提供接口，等著Presenter來調用時返回相應數據即可，這和經典MVC模式中是非常不同的，在MVC中Model在數據發送變化后，是需要發送廣播來告之View去更新用戶界面的，而在MVP中，Model是不應該去通知View，而是通知Presenter來間接的更新View的。
而Presenter和Model的關系也應該是基于接口來通信，這樣才能把Model和Presenter的耦合度也降到最低，那么在需要改變Model內部實現，甚至徹底替換Model的時候，Presenter則是無需隨之改變的。這樣做帶來的另一個好處就是你可以通過Mock一個Model來對Presenter以及View做模擬測試了，從而提高了可測試性。
那么View和Presenter的關系呢？View是需要擁有對Presenter的引用，但僅僅是為了將用戶的操作和事件立即傳遞給Presenter，為了讓View和Presenter耦合較低，View也只應該通過接口與Presenter通信，從而保證View是完全被動的，一方面它由用戶的操作觸發來和Presenter通信，另一方面它完全受Presenter控制，唯一需要做的事情就是如何展示數據。
簡要總結三者之間的關系是：View和Model之間沒有聯系，View通過接口向Presenter來傳遞用戶操作，Model不主動和Presenter聯系，被動的等著Presenter來調用其接口，Presenter通過接口和View/Model來聯系。
View <- 接口 <- Presenter ->接口 -> Model
View -> 接口 -> Presenter <- 接口 <- Model
Talk is cheap, show me the code
為了便于理解，這里提供一些偽代碼加注釋演示一下如何實現MVP模式：
View
interface IUserView {
void setPresenter(presenter);
void showUsers(users);
void showDeleteUserComplete();
void showDeleteUserError();
}
class UserView implements IUserView {
UserPresenter presenter;
// 保持對Presenter的引用，用于路由用戶操作
void setPresenter(presenter) {
this.presenter = presenter;
}
// 將Presenter傳遞來的數據展示出來
void showUsers(users) {
draw(users);
}
// Model操作數據成功后，通過Presenter來告之View需要更新用戶界面
void showDeleteUserComplete() {
alert("Delete User Complete");
}
// Model操作數據失敗后，也是通過Presenter來告之View需要更新用戶界面
void showDeleteUserError() {
alert("Delete User Fail");
}
// 當用戶點擊某個按鈕時，將用戶操作路由給presenter，由presenter去處理
void onDeleteButtonClicked(event) {
presenter.deleteUser(event);
}
}
Model
interface IUserModel {
List<User> getUsers();
boolean deleteUserById();
}
class UserModel implements IUserModel {
// 在數據庫里查找數據，并將數據返回給presenter
List<User> getUsers() {
return getUsersInDatabase(id);
}
// 在數據庫里刪除數據，并將結果返回給presenter
User deleteUserById(id) {
return deleteUserByIdInDatabase(id);
}
}
Presenter
interface IUserUserPresenter {
void deleteUser(event);
}
class UserUserPresenter implements IUserPresenter {
// 保持對View的引用
IUserView view;
// 保持對Model的引用
IUserModel model;
UserUserPresenter(IUserView view, IUserModel model) {
this.view = view;
this.model = model;
this.view.setPresenter(this);
}
void start() {
// 從Model中取出數據
List<User> users = model.getUsers();
// 將數據發送給View，讓其展示到用戶界面
view.showUsers(users);
}
void deleteUser(event) {
// View將用戶操作路由過來，由Presenter來處理
long uid = whichUserNeedToDeleteBy(event);
// 將用戶操作翻譯成命令或消息傳遞給model，以改變數據
boolean success = model.deleteUserById(uid);
// 將Model操作數據后的結果通知View來改變用戶界面
if (success) {
view.onDeleteUserSuccess();
} else {
view.onDeleteUserFail();
}
}
}
OK，到此一個最簡單的MVP模式就實現了，可以看到整個架構的輪廓已經很清晰了，而且面向接口編程也帶來了很多的好處，讓代碼之間藕和較少，對測試支持也更為友好，理解和維護起來也更加方便了。
以后有時間再為大家描述如何在android里面實現MVP模式，以便更具體的理解。有疑問歡迎參與討論，大家一起學習進步。
