在寫網(wǎng)絡服務器的邏輯時,常常避免不了需要向 另一個服務器 發(fā)送協(xié)議, 直到等待返回成功, 再繼續(xù)下一步的操作
這時候, 代碼可能是這樣的
RemoteObj.call( PROTOCOL_A,??param, callBackFun?);
注:
PROTOCOL_A 是協(xié)議號
param 是參數(shù)
callBackFun 是回調(diào)函數(shù)
甚至有時還需要寫? onError / onTimeout 之類的回調(diào)
這樣,?? 一個業(yè)務邏輯被"分割"在兩個甚至多個函數(shù)內(nèi)去寫
再假設,??
向 服務器A? 請求,? 需要等待 服務器A 返回成功后,? 取到數(shù)據(jù), 再向 服務器B 請求, 需要等待 服務器B 返回成功后, ...... (后面省略10000字)
這樣的話,?
在寫業(yè)務邏輯時,? 思路常常被中斷,? :) 有時寫完一個回調(diào)函數(shù), 前面考慮的異常已經(jīng)忘記了?
在看業(yè)務邏輯時,? 思緒在不同的函數(shù)間 跳來跳去,? 容易看錯或看漏東西.
我還假設,?? 如果代碼只需要這樣寫
Response?resp = RemoteObj.call( PROTOCOL_A,??param);
if ( resp.RetCode == SUCCESS?)
......
call 函數(shù)內(nèi)部其實是一個遠程調(diào)用, 發(fā)協(xié)議到其它服務器, 等其返回協(xié)議后, 直接在 Response 就可以取 對方返回的協(xié)議內(nèi)容, 當然 timeout
Response 也應該返回錯誤碼
再簡單一點說, 就是寫 遠程調(diào)用不需要 callback, 不需要實現(xiàn)? onError / onTimeout 之類的東西
寫法就跟調(diào)用一個函數(shù)一樣方便
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
現(xiàn)階段, 似乎對 "遠程調(diào)用 同步的寫法" 并沒有很好的解決方案,
網(wǎng)上看了些遠程調(diào)用框架, 也避免不了要寫 callback
需要實現(xiàn)也可以, 但并不是優(yōu)雅的實現(xiàn)方案
例如:
可以在 call() 里面等待一個信號, 另一個線程等待接受協(xié)議返回后, 再激活這個信號, 但總不能一個 call() 調(diào)用就阻塞一條線程吧?
還可以 用 throw expcetion / long jump / goto 來實現(xiàn)調(diào)用 call() 發(fā)完協(xié)議后先 return , 等協(xié)議返回后, 再繼續(xù) goto到? call() 之后的代碼, 這是最不優(yōu)雅的做法了
再可以 用 一堆宏把 callback / ontimeout / onerror 之類的函數(shù)"屏蔽"掉, 也不是優(yōu)雅的做法, 用宏實現(xiàn), 有時一個簡單的語法錯, 可能都要找半天
甚至可以 弄自己的一套語法解析,? 自己寫一個語法解析的工具,? 寫完代碼后, 再運行去 解析代碼里的所有? callback , 再換成? callback / ontimeout / onerror 的函數(shù)
無論哪種實現(xiàn), 都要注意, 在調(diào)用? callback 時, 要緩存當前所有的臨時變量, 在對方服務器返回協(xié)議后, 再恢復這些臨時變量, 這樣才可以真正做到
"遠程調(diào)用 同步的寫法"
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
說了大半天, 還是沒有解決方案, 只是一時突發(fā)的一個想法, 記錄之
?