MVC 與 MVP 的抉擇

古人有句話說「十年河東、十年河西」，前幾年在 Android 開發上，MVC 的設計一直是眾人談論的重點。但是隨著時間的更替，MVP 似乎開始熱了起來，連 Google 自家的範例中都提供了 MVP 的設計樣板，MVC 反而不在示範之列。

這讓很多人會興起一個疑問是：

MVC 和 MVP 我該選哪一個？我真的該棄 MVC 改投 MVP 的懷抱嗎？

面對這樣的一個問題，讓我想到了星爺電影中的一句台詞：

爭什麼爭，把兩樣摻在一起做瀨尿牛丸不就得了，笨蛋！

聽起戲謔，但卻不失為一個設計上可以思考的方向。MVC 和 MVP 的示意圖相信很多人可以信手捻來，並且解說得頭頭是道。但各位可曾想過一個問題，這些示意圖轉成實際的 Class Diagram 之後，都只能各自對應到一個 Class？如果把 V 視為一個 Sub-System，在設計上是不是可以有更多的可能性？

舉個例子，下面的這個示意圖是以 MVP 為主體，然後 View 的角色以 MVC 代換進去。

同理可證，如果不想要套用 MVC，那可不可以用 Facebook 的 Flux 架構代入？好像也沒什麼不可以，換完之後就像以下的示意圖：

如此設計上的變化，帶來了某種程度上的彈性。假設今天有個系統原本是在 App 上開發的，但需要移往 Web 平台。而 MVP 的 Model 就像前一段所說，不是一個 Class，而是代表 Business Logic 的 Sub-System。當前端顯示平台在做轉換時，可以由示意圖中看出在 Presenter 這半邊的設計是可以保持不變的，也就是說在設計上可以保持最大程度的重用性。以上面二個示意圖來說，原本在 App 中是以 MVC 的架構來提供畫面的呈現，而移到 Web 平台之後，則可以改採適合 Web 的架構來作為畫面呈現的基礎，相關的 Business Logic 則不需要更改。

當然以上是針對設計的部份，如果連 Source Code 都要可以重用，則不可能這麼直接地就達成目的。以上面的例子來看，如果原本開發的 App 是在 iOS 平台上，我想應該不會有人想要用 Objective-C 來開發一個網站吧！在這樣的情況之下所有的 Source Code 勢必得重新來過，只是相對地比起其他全新網站的 Case 來說，省下了不少在設計上所需的工作。

不過要讓 Source Code 可以重用也不是不可能實現，只是在設計的階段就必須要做好規劃。一開始就要讓代表 Business Logic 的 Model 與 Presenter 的互動是以 Remote 的方式進行，如此一來，不論前端的顯示平台是什麼技術、什麼架構，都可以直接重用 Business Logic 的 Source Code。

知易行難，概念上並不複雜，在實作上卻是有很多的細節需要考量，未來有機會將另闢篇幅針對更細部的設計做進一步的討論。

再把焦點拉回到主題上，其實要選擇 MVC 或 MVP 並沒有人可以告訴你正確的答案。因為每個 Case 都具有一定的獨特性，沒有方案是萬用的，只有最適合的。以上面提到的設計手法來說，在某種程度上是把設計給複雜化了，如果你沒有跨平台的需求，又或者你的畫面簡單到只有一、二個，這樣的設計手法就顯得疊床架屋、累贅了點。

所以當你在擔任設計的工作時，要選擇哪一個架構對目前的 Case 來說是最適合的，是你責無旁貸的課題。這是需要經驗，也是需要時間去思考的。你的煩惱也是其他正在設計系統的人所煩惱的，而你要做的、能做的也只有從不斷地嘗試與調整中成長。