古人有句話說(shuō)“十年河?xùn)|、十年河西”，前幾年在 Android 開(kāi)發(fā)上，MVC 的設(shè)計(jì)一直是眾人談?wù)摰闹攸c(diǎn)。但是隨著時(shí)間的更替，MVP 似乎開(kāi)始熱了起來(lái)，連 Google 自家的示例中都提供了 MVP 的設(shè)計(jì)樣板，MVC 反而不在示例之列。
這讓很多人會(huì)興起一個(gè)疑問(wèn)是：
MVC 和 MVP 我該選哪一個(gè)？我真的該棄 MVC 改投 MVP 的懷抱嗎？
面對(duì)這樣的一個(gè)問(wèn)題，讓我想到了星爺電影中的一句臺(tái)詞：
爭(zhēng)什么爭(zhēng)，把兩樣摻在一起做瀨尿牛丸不就得了，笨蛋！
聽(tīng)起戲謔，但卻不失為一個(gè)設(shè)計(jì)上可以思考的方向。MVC 和 MVP 的示意圖相信很多人可以信手捻來(lái)，并且解說(shuō)得頭頭是道。但各位可曾想過(guò)一個(gè)問(wèn)題，這些示意圖轉(zhuǎn)成實(shí)際的 Class Diagram 之后，都只能各自對(duì)應(yīng)到一個(gè) Class？如果把 V 視為一個(gè) Sub-System，在設(shè)計(jì)上是不是可以有更多的可能性？
舉個(gè)例子，下面的這個(gè)示意圖是以 MVP 為主體，然后 View 的角色以 MVC 代換進(jìn)去。
同理可證，如果不想要套用 MVC，那可不可以用 Facebook 的 Flux 架構(gòu)代入？好像也沒(méi)什么不可以，換完之后就像以下的示意圖：
如此設(shè)計(jì)上的變化，帶來(lái)了某種程度上的彈性。假設(shè)今天有個(gè)系統(tǒng)原本是在 App 上開(kāi)發(fā)的，但需要移往 Web 平臺(tái)。而 MVP 的 Model 就像前一段所說(shuō)，不是一個(gè) Class，而是代表 Business Logic 的 Sub-System。當(dāng)前端顯示平臺(tái)在做轉(zhuǎn)換時(shí)，可以由示意圖中看出在 Presenter 這半邊的設(shè)計(jì)是可以保持不變的，也就是說(shuō)在設(shè)計(jì)上可以保持最大程度的重用性。以上面二個(gè)示意圖來(lái)說(shuō)，原本在 App 中是以 MVC 的架構(gòu)來(lái)提供畫面的呈現(xiàn)，而移到 Web 平臺(tái)之后，則可以改采適合 Web 的架構(gòu)來(lái)作為畫面呈現(xiàn)的基礎(chǔ)，相關(guān)的 Business Logic 則不需要更改。
當(dāng)然以上是針對(duì)設(shè)計(jì)的部份，如果連 Source Code 都要可以重用，則不可能這么直接地就達(dá)成目的。以上面的例子來(lái)看，如果原本開(kāi)發(fā)的 App 是在 iOS 平臺(tái)上，我想應(yīng)該不會(huì)有人想要用 Objective-C 來(lái)開(kāi)發(fā)一個(gè)網(wǎng)站吧！在這樣的情況之下所有的 Source Code 勢(shì)必得重新來(lái)過(guò)，只是相對(duì)地比起其他全新網(wǎng)站的 Case 來(lái)說(shuō)，省下了不少在設(shè)計(jì)上所需的工作。
不過(guò)要讓 Source Code 可以重用也不是不可能實(shí)現(xiàn)，只是在設(shè)計(jì)的階段就必須要做好規(guī)劃。一開(kāi)始就要讓代表 Business Logic 的 Model 與 Presenter 的互動(dòng)是以 Remote 的方式進(jìn)行，如此一來(lái)，不論前端的顯示平臺(tái)是什么技術(shù)、什么架構(gòu)，都可以直接重用 Business Logic 的 Source Code。
知易行難，概念上并不復(fù)雜，在實(shí)作上卻是有很多的細(xì)節(jié)需要考量，未來(lái)有機(jī)會(huì)將另辟篇幅針對(duì)更細(xì)部的設(shè)計(jì)做進(jìn)一步的討論。更多深入的文章請(qǐng)參閱 http://www.lxweimin.com/u/fea63707e07f。
再把焦點(diǎn)拉回到主題上，其實(shí)要選擇 MVC 或 MVP 并沒(méi)有人可以告訴你正確的答案。因?yàn)槊總€(gè) Case 都具有一定的獨(dú)特性，沒(méi)有方案是萬(wàn)用的，只有最適合的。以上面提到的設(shè)計(jì)手法來(lái)說(shuō)，在某種程度上是把設(shè)計(jì)給復(fù)雜化了，如果你沒(méi)有跨平臺(tái)的需求，又或者你的畫面簡(jiǎn)單到只有一、二個(gè)，這樣的設(shè)計(jì)手法就顯得疊床架屋、累贅了點(diǎn)。
所以當(dāng)你在擔(dān)任設(shè)計(jì)的工作時(shí)，要選擇哪一個(gè)架構(gòu)對(duì)目前的 Case 來(lái)說(shuō)是最適合的，是你責(zé)無(wú)旁貸的課題。這是需要經(jīng)驗(yàn)，也是需要時(shí)間去思考的。你的煩惱也是其他正在設(shè)計(jì)系統(tǒng)的人所煩惱的，而你要做的、能做的也只有從不斷地嘗試與調(diào)整中成長(zhǎng)。
