2017/3/31

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 來說是最適合的,是你責無旁貸的課題。這是需要經驗,也是需要時間去思考的。你的煩惱也是其他正在設計系統的人所煩惱的,而你要做的、能做的也只有從不斷地嘗試與調整中成長。