在Android開發中使用MVP和MVVM模式早已不是新鮮事了，各種MVP/MVVM相關的文章、開源庫也已屢見不鮮，甚至是讓人眼花撩亂，那么我為什么還要在這個早已被畫滿涂鴉的黑板上再來涂涂畫畫呢?是想彰顯我的存在感嗎?那當然!啊不不不……不完全是!我還想要警醒讀到這篇文章的各位：你們對于MVX的理解可能并不完全正確!

注：這篇文章里我將使用 MVX 做為MVC、MVP以及MVVM的統稱。

我們都知道MVX的進化過程是從滾球獸進化到MVC，然后從MVC進化到MVP，再從MVP超進化到MVVM。那么接下來，按照常規的套路，我應該要介紹什么是MVC，什么是MVP，以及什么是MVVM，并且分別介紹M、V、C/P/VM各自的職責了。

[[280783]]

我的目的是想要糾正一些對MVX的錯誤認識，所以前提是你要對MVX有一些了解。為了避免有人在使用MVX時走上彎路，所以決定對我看到的一些關于MVX的錯誤認識進行總結以及糾正。會產生這些錯誤認知的原因，經我分析，其實是：沒有真正領會到MVX主義的核心價值觀!其實MVX的核心思想也很簡單，不要誤會，不是富強、民主、……而是 將表現層和業務層分離 。

表現層和業務層分離

表現層和業務層分離，Matin Fowler稱之為Separated Presentation。這里的表現層就是VX，業務層就是M。如果有人看到這里發現了和你認為的MVX不一樣的話，那么你對MVX的認識很可能就存在錯誤，嚴重者還可能是走了修正主義路線!

從表現層和業務層分離的視角來看，M、V、X不是平等的身份，應該是M和V-X。自始自終M的職責都沒變，變的是V-X，隨著軟件開發技術的發展、交互形式或者交互媒介的不斷改變，表現層的邏輯也越來復雜，MVX的進化過程就是一個不斷探尋處理表現層復雜邏輯的過程。當然從一個形態進化到另一個形態，并不一定是為了解決更復雜的交互邏輯，也可能是有了一種“更優雅”的方式來處理表現層邏輯。

既然已經有表現層和業務層分離的概念了，那么第一個錯誤觀點就很好解釋了。

錯誤一：Presenter或者ViewModel負責處理業務邏輯

這是一個很常見的錯誤觀點，很多介紹MVP或者MVVM的文章都這么說過。正如前面所說，業務邏輯是屬于M層的，那Presenter或者ViewModel是干什么的，處理表現層邏輯的嗎?是的，或者說大部分表現層邏輯都是在Presenter或者ViewModel中處理的。之前我將業務層之上的這些邏輯稱之為視圖邏輯，現在為了統一就叫做表現層邏輯吧(加個吧字怎么感覺怪怪的)。

我在這里就簡單說一下什么是表現層邏輯，以及View和Presenter/ViewModel又是如何分工的。假設你的應用有一個個人資料的profile頁面，這個頁面有兩種狀態，一種是瀏覽狀態，一種是編輯狀態，通過一個編輯按鈕觸發狀態的轉換，編輯狀態時，部分信息項可以進行編輯。那這里就有一個明顯的表現層邏輯，那就是點擊按鈕切換瀏覽/編輯狀態。

現在的MVP的流行形態(或者變種)叫做Passive View，它和MVVM一樣現在都傾向于將幾乎所有的表現層邏輯交給Presenter或者ViewModel處理，View層需要做的事情很少，基本上就是接受用戶事件，然后將用戶事件傳遞給Presenter或者ViewModel。以上面的profile頁面的例子來解釋的話就是，View層負責接收編輯按鈕的點擊事件，然后通知Presenter/ViewModel，然后Presenter/ViewModel通知View是顯示瀏覽狀態的視圖還是編輯狀態的視圖。MVP的示例代碼大概是這樣的：

public class ProfileView { 
    void initView() { 
        // 負責注冊點擊事件監聽器，并將點擊事件通知給presenter 
        editStateButton.setOnClickListener(new OnClickListener() { 
            presenter.onEditStateButtonClicked(); 
        }) 
        ... 
    } 
 // 顯示瀏覽狀態視圖，想不到好名字，就叫showNormalState吧 
    public void showNormalState() { 
        // 瀏覽狀態下編輯按鈕提示文字為“編輯”，所有項不可編輯 
        editStateButton.setText("編輯"); 
        nickName.setEditable(false); 
        ... 
    } 
    public void showEditState() { 
        // 瀏覽狀態下編輯按鈕提示文字為“完成”，部分項要設置為可編輯 
        editStateButton.setText("完成"); 
        nickName.setEditable(true); 
        ... 
    } 
} 
 
 
public class ProfilePresenter { 
    private State curState = State.NORMAL; 
    public void onEditStateButtonClicked() { 
        // 按鈕被點擊時，根據當前狀態判斷View應該切換顯示的狀態 
        // 這就是表現層邏輯 
        if (isInEditState()) { 
            curState = State.NORMAL; 
            view.showNormalState(); 
        } else { 
            curState = State.EDIT; 
            view.showEditState(); 
        } 
    } 
    private boolean isInEditState() { 
        return curState == State.EDIT; 
    } 
    @VisibleForTest 
    void setState(State state) { 
        curState = state; 
    } 
} 

注：這個示例代碼只是為了展示表現層邏輯，沒有涉及到Model層，編譯也不會通過的!

能感受到我想表達的意思嗎?就是Presenter/ViewModel根據當前交互狀態決定該顯示什么，而View要做的是如何顯示它們。再比如說下拉刷新的場景，由View告訴Presenter/ViewModel，它接收到了下拉事件，然后Presenter/ViewModel再告訴View，讓它去顯示刷新提示視圖，至于這個刷新提示長什么樣就由View來決定。當然Presenter/ViewModel也可能會判斷當前網絡不可用，而讓View顯示一個網絡不可用的提示視圖。

為什么要讓Presenter/ViewModel處理幾乎所有的表現層邏輯呢?主要是為了提高可測試性，將盡可能多的表現層邏輯納入到單元測試的范圍內。因為對視圖控件的顯示等等進行單元測試太難了，所以View是基本上沒法進行單元測試的，但是Presenter/ViewModel是完全可以進行單元測試的：

public class ProfilePresenterTest { 
    private ProfilePresenter presenter; 
    private ProfileView view; 
    @Test 
    public void testShowEditStateOnButtonClick() { 
        // 瀏覽狀態下點擊編輯按鈕，驗證View是否顯示了編輯狀態視圖 
        // 也就是驗證view.showEditState()方法是否被調用了 
        presenter.setState(State.NORMAL); 
        presenter.onEditStateButtonClicked(); 
        Mockito.verify(view).showEditState(); 
    } 
    @Test 
    public void testShowNormalStateOnButtonClick() { 
        // 編輯狀態下點擊完成按鈕，驗證View是否顯示了瀏覽狀態視圖 
        // 也就是驗證view.showNormalState()方法是否被調用了 
        presenter.setState(State.EDIT); 
        presenter.onEditStateButtonClicked(); 
        Mockito.verify(view).showNormalState(); 
    } 
} 

你看，這些表現層邏輯就都能進行單元測試了吧!大概懂我意思了吧?

[[280784]]

OK，現在你已經知道表現層了，那業務層又是干什么用的呢?現在我們就要開始談到M了。

M是什么?M是指那些喜歡從受虐中獲得性……哎呀，不好意思，搞混了!哎～學識淵博就是麻煩!M者，Model也，再長一點就是Domain Model，中文名字叫領域模型。我們看一下維基百科上對Domain model的定義：

• In software engineering, a domain model is a conceptual model of the domain that incorporates both behaviour and data.

怎么樣，是不是很通俗易懂呀?當然不是!剛剛開始有點理解Model層是處理業務邏輯的，現在又來了個抖MMM……Domain，我都不知道該往哪里去想了!Domain，簡單點就把它理解成業務，我覺得都沒啥問題。我這里引用這句話，主要是想強調，Model層包含了業務數據以及對業務數據的操作(behaviour and data)，也是為了引出第二個錯誤觀點。

錯誤二：Model就是靜態的業務數據

我們做業務模塊開發時，會經常定義一些數據結構類，比如個人資料可能會對應一個UserProfile類，一條訂單數據可能會對應一個Order類，這些類沒有任何邏輯，只有一些簡單的getter、setter方法。有些人會認為像UserProfile或者Order這樣的數據結構類就是Model。

我們已經強調了，Model層包含了業務數據以及對業務數據的操作。像UserProfile或者Order這樣的數據結構類的實例甚至都不能稱之為對象，可以看一下Uncle Bob的Classes vs. Data Structures這篇文章，對象是有行為的，一個數據結構實例沒有行為，連對象都稱不上，怎么能代表Model層呢!

靜態的業務數據不能代表Model層，業務數據以及針對業務數據的操作共同構成了Model層，這也就是業務邏輯。再舉個例子說一下吧，假設你在做一個叫“掘鐵”的app，這個app現在只有一個頁面，用來展示推薦的博客列表。OK，我們如果用MVP的形式該怎么寫呢?我們就先不管和Model層完全沒有交互的View了，Presenter層除了處理表現層邏輯外，還要向Model層發出業務指令，注意，Presenter并不處理業務邏輯，真正的業務邏輯還是由Model層完成。示例代碼大概是下面這樣：

public class RecommendBlogFeedPresenter { 
    private RecommendBlogFeedView view; 
    private BlogMode model; 
    public void onStart() { 
        view.showLoadWait(); 
        model.loadRecommendBlogs(new LoadCallback<>() { 
            @Override 
            public void onLoaded(List<Blog> blogs) { 
                view.showBlogs(blogs); 
            } 
        }) 
    } 
} 
 
 
public interface BlogModel { 
    void loadRecommendBlogs(LoadCallback<List<Blog>> callback); 
} 
public class BlogModelImpl implements BlogModel { 
    private BlogFeedRepository repo; 
    @Override 
    public void loadRecommendBlogs(LoadCallback<List<Blog>> callback) { 
        // BlogFeedRepository.fetch()很可能是耗時操作，所以實際寫的時候會在非主線程執行，這里只是示例 
        callback.onLoaded(repo.fetch("recommend")); 
    } 
} 
public interface BlogFeedRepository { 
    List<Blog> fetch(String tag); 
} 

什么?你這個BlogModelImpl里就這一行代碼，你跟我說這是業務邏輯?大家冷靜一下，把手里的板磚、砍刀、狼牙棒先放下來。BlogModelImpl類里面的邏輯雖然簡單，但是它的確是業務邏輯，也正是因為業務邏輯比較簡單，所以BlogModelImpl類才會很簡潔。

再從Presenter的角度看一下，為什么loadRecommendBlogs()屬于業務邏輯。博客這個概念毫無疑問屬于業務概念，根據前面的解釋應該可以判斷出來“獲取推薦的博客列表”不屬于表現層邏輯，那么這個邏輯的實現就不是Presenter需要關心的，那就應該是Model層的職責，既然是Model層的那就應該是業務邏輯了;再者，既然博客是業務概念，那么Blog就是業務數據的數據結構，loadRecommendBlogs()涉及到對業務數據Blog的創建及組裝等操作，所以也應該是業務邏輯。

看到這里，可能有些人會產生一些誤解：所謂的業務邏輯處理就是網絡請求、數據庫查詢等數據獲取邏輯，即Model層就是負責數據獲取的，這也是我要說的第三個錯誤觀點。稍等，我先寫個標題⬇

錯誤三：Model層就是負責數據獲取的

產生這種錯誤認識的，說白了還是沒有搞懂業務邏輯。當然了業務邏輯本身就是很抽象的概念，難理解，也很難區分，我也不敢往細了去說，因為說多了怕被你們發現其實我也是在裸泳。

業務邏輯層并不負責數據的獲取，數據的獲取職責還要在Model層的更下層，這也是為什么我要把的BlogModel的實現邏輯寫得如此簡單，因為數據獲取的職責全部交給了BlogFeedRepository類，Model層只處理業務邏輯。BlogFeedRepository是博客列表的倉儲類，BlogModel通過BlogFeedRepository的fetch()方法獲取標簽為recommend的博客列表，也就是推薦的博客列表。BlogModel不關心BlogFeedRepository是如何獲取對應博客數據的，它可以是從通過網絡請求獲取的，也可以是從本地數據庫中獲取的，數據源有任何改變也不應該影響到BlogModel中的業務邏輯。

那么既然BlogModel中的業務邏輯如此簡單，為什么要強行增加這么一個Model層，而不是讓Presenter直接使用BlogFeedRepository類去獲取數據呢?

當然是有原因的!假設我們剛才介紹的“掘鐵”app，在僅有一個博客列表頁面的情況下，依然吸引了很多用戶去使用，產品經理此時決定嘗試探索變現手段，首先是在博客推薦列表中添加廣告數據。再假設，由于廣告數據和博客數據分屬不同的后端團隊，兩邊數據尚未整合打通，暫時由客戶端負責把廣告數據添加到博客列表中。這個時候，BlogModel終于凸顯了它存在的必要性。表現層不負責廣告數據的獲取與整合，BlogFeedRepository也不能負責廣告數據的獲取與整合。廣告數據的整合是業務邏輯，由BlogModel負責，廣告數據的獲取由專門的數據倉儲類負責。示例代碼如下：

public class BlogModelImpl implements BlogModel { 
    private BlogFeedRepository blogRepo; 
    private AdRepository adRepo; 
    private BlogAdComposeStrategy composeStrategy; 
    private AdBlogTransform transform; 
    @Override 
    public void loadRecommendBlogs(LoadCallback<List<Blog>> callback) { 
        List<BlogAd> ads = adRepo.fetch("recommend"); 
        List<Blog> blogs = blogRepo.fetch("recommend"); 
        // 在這里把廣告數據整合到博客列表中 
        blogs = composeStrategy.compose(blogs, ads, transform); 
        callback.onLoaded(blogs); 
    } 
} 
public interface AdRepository { 
    List<BlogAd> fetch(String tag); 
} 
public interface BlogAdComposeStrategy { 
    List<Blog> compose(List<Blog> blogs, List<BlogAd> ads, AdBlogTransform transoform); 
} 
public interface AdBlogTransform { 
    Blog transform(BlogAd ad); 
} 

考慮到廣告和博客可能有不同的整合策略，可以按需替換不同的實現，所以把整合策略封裝到了BlogAdComposeStrategy接口中。整合策略也屬于業務邏輯，但是因為整合策略的實現細節這里不需要關注，所以我覺得不寫出來也行，反正都是我編的。

這里我想表達的是，獲取廣告數據并將廣告數據整合到博客列表中也是業務邏輯的一部分，如果省略Model層將會造成得把廣告的整合邏輯放到Presenter或者Repository層，這必然都是不合適的。將業務邏輯放到了錯誤的層次里，勢必會造成后續的維護性和擴展性問題。

錯誤四：Model層依賴Presenter/ViewModel層

還有一些人沒有搞清楚Model層和上層的依賴關系，依賴關系寫成了雙向的，這是不對的，業務層不應該依賴表現層，而是應該反過來。

實際上應該是Presenter/ViewModel通過接口的形式依賴Model層，Model層完全不依賴Presenter/ViewModel。就像我前面的示例代碼里一樣，Model層必然不會出現任何presenter這樣的單詞，上層通過觀察者模式來監聽Model層的數據變化(LoadCallback接口也算是一種)，Model層也不用關心上層是Presenter還是ViewModel。

最后

讀到這里，不知道你們對MVX的理解是不是更深了些呢?對表現層邏輯、業務邏輯是不是也有了更清晰的認識了呢?

其實關于MVX還有更多可以討論的，比如有些人認為Model層并不是真正處理業務邏輯的地方，它只是業務模塊的一個上層封裝層，我覺得也不無道理，在復雜業務模塊中，業務是存在層次的，MVX中的Model層是所有業務層中的最上層。

還有我剛剛提到的業務層之下還有數據層，這是典型的三層架構的概念，即表現層、業務層和數據層。邏輯存在分層，所以架構也必然要進行分層，MVX可以做為我們從代碼到業務甚至到架構的探索的開端。