移動(dòng)客戶端業(yè)務(wù)層組件化(2)- 不重復(fù)造輪子

我們要堅(jiān)信絕大部分問題,其他人早就遇到過,并且很可能有絕佳的解決方案,即使沒有,至少別人踩過的坑,我們不必再踩一次。所以對(duì)于組件化,也是一樣,我們要避免重復(fù)造輪子。于是,第一件事我們要做的就是找這個(gè)輪子。

iOS的兩個(gè)輪子:

(1)Limboy(蘑菇街)的組件化方案:
http://limboy.me/ios/2016/03/10/mgj-components.html
http://limboy.me/ios/2016/03/14/mgj-components-continued.html
(2)Casa(天貓)的組件化方案:
http://casatwy.com/iOS-Modulization.html

這兩組文章可以結(jié)合著看,非常有意思,另外底下評(píng)論的內(nèi)容更精彩,有點(diǎn)像兩個(gè)高手在擂臺(tái)上切磋,底下有一堆圍觀助威點(diǎn)贊的。
文章自己看就好,很長,內(nèi)容很豐富,甚至Casa還寫了一個(gè)Demo來論證自己的觀點(diǎn),我們?nèi)ゴ秩【?,深入分析一下?/p>

英雄所見略同:

我們先看看兩個(gè)同學(xué)意見相同的地方:

  1. 組件間的通訊涉及到傳參問題,那么這個(gè)參數(shù)首先需要去Model化,否則調(diào)用者和被調(diào)用者都需要持有Model的引用,達(dá)不到解耦的目的。
    (去Model化會(huì)帶來一個(gè)問題,就是參數(shù)需要以NSDcitionary的方式傳遞,勢必會(huì)影響開發(fā)效率,因?yàn)檎{(diào)用雙方需要約定好各種Key,以及Key有問題時(shí)能夠準(zhǔn)確拋出相關(guān)的異常)
  2. 組件間通訊的參數(shù)需要分為常規(guī)(能夠使用JSON進(jìn)行序列化的對(duì)象)和非常規(guī)。
  3. 對(duì)于遠(yuǎn)程APP調(diào)用,都使用openUrl的方式(這個(gè)算是廢話,蘋果只支持這個(gè)),并且過程基本一致:openUrl-> parse-> target-action

求同存異

再看看兩個(gè)同學(xué)意見相左的地方:

  1. 發(fā)現(xiàn)服務(wù):
    Limboy采用應(yīng)用初始化,各個(gè)組件向ModuleManager注冊的方式。
    Casa采用iOS runtime機(jī)制,使用Mediator+target-action方式自動(dòng)發(fā)現(xiàn)服務(wù),免注冊化。
  2. 組件間通訊問題:
    Limbo的方案,對(duì)于常規(guī)參數(shù),使用openUrl方式,非常規(guī)參數(shù)使用注冊protocol的方式,通過publicProtocol暴露出需的類和方法,所有組件持有這個(gè)publicProtocol。
    Casa的方案,分為遠(yuǎn)程調(diào)用和本地調(diào)用,遠(yuǎn)程調(diào)用的方式是openUrl方式,本地調(diào)用采用target-action方式,通過category將方法暴露出去,省去了注冊的這一步。
  3. 調(diào)用組件頁面的細(xì)節(jié):
    Limbo的方案是:調(diào)用者傳入相關(guān)參數(shù)發(fā)起調(diào)用 -> 響應(yīng)方收到調(diào)用 -> 響應(yīng)方創(chuàng)建頁面實(shí)例并pushViewController。
[MGJRouter registerURLPattern:@"mgj://detail?id=:id" toHandler:^(NSDictionary *routerParameters) {
    NSNumber *id = routerParameters[@"id"];
    // create view controller with id
    // push view controller
}];

Casa的方案是:調(diào)用者傳入相關(guān)參數(shù)發(fā)起調(diào)用 -> 響應(yīng)方收到調(diào)用 -> 響應(yīng)方創(chuàng)建頁面實(shí)例并返回 -> 調(diào)用方拿到實(shí)例后進(jìn)行處理。

我們可以看到Limboy方案的好處是:調(diào)用方不需要關(guān)心響應(yīng)方的邏輯,只需要正確調(diào)用方法和傳遞參數(shù)即可,缺點(diǎn)是不夠靈活,如果調(diào)用方想Present而不是Push呢?而Casa的方案正好相反。
我個(gè)人更傾向Casa的方案,雖然代碼會(huì)長一些,但是清晰,對(duì)于這種跨組件的調(diào)用,清晰是第一位的,否則業(yè)務(wù)工程師很容易懵逼。

推薦另外一個(gè)同學(xué)bang(JSPatch的作者)的分析:http://blog.cnbang.net/tech/3080/

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

推薦閱讀更多精彩內(nèi)容