細節 關於非同步呼叫的解決方案

2021-09-05 14:19:06 字數 1661 閱讀 4638

net66

曾發表過一篇

《銜接ui執行緒和管理後台工作執行緒的類(多執行緒、非同步呼叫)

》來說明如何處理後台執行緒通過非同步方式來更新

ui。他的方案非常棒,但是客戶端稍稍複雜了一點,在非常複雜的場景可能會發生問題。我在實際工作中遇到這個問題的時候不是以非同步委託的面目出現的,而是以介面方式實現的,這樣的情況更具有一般性。我通常是在若干個訂閱端

(subscriber)

實現這個「訂閱主題」的介面,在乙個發布端

(publisher)

實現同樣乙個介面,並提供對訂閱者的管理。事實上,在業務層實現這個發布端的介面是容易的,但在

gui的訂閱端有可能會發生另外一些問題,例如如果業務端與

gui客戶端並不在同乙個執行緒中。典型的例子就是通常將「長任務」放到某個後台執行緒中去執行,在執行過程中可以在任何時候將執行狀態報告給前台執行緒。顯然,這是乙個處理一般性

observe

模式的通用方案。

實現的方法有點**,和

mixin

的原理很相似。在乙個

asyncobjectbase

的基類或者該基類的派生類上動態實現客戶端介面,同時實現對訂閱者的管理。之所以動態化是為了適應客戶端介面中的任何簽名的方法。

以下是關於

asyncobjectbase

的簡單的

api:

提供了兩個方法來管理訂閱者:

register(object)

:新增訂閱者。

unregister(object)

:刪除訂閱者。

提供了三個方法來管理發布狀態:

disable()

:關閉發布。

enable(object)

:僅開放指定的訂閱者。

enable()

:開放所有的訂閱者。

提供了兩個靜態方法來例項化介面的服務端實現:

asyncobjectbase getobject(type, type)

:獲取指定基類、指定介面型別的服務端實現

(指定基類必須繼承自

asyncobjectbase)。

asyncobjectbase getobject(type)

:獲取指定介面型別的服務端實現。

從asyncobjectbase

派生乙個自定義型別來重寫委託指派方法可實現複雜的委託

(不僅限於基於

system.windows.form.control

的實現類

)。這三個方法是:

void checkdelegate(delegate, object, out bool);

object checjdelegate2(delegate, object, out bool);

以上兩個方法都是捕獲委託的,差異是前者實現的委託無返回值,而後者實現的委託有返回值。最後乙個引數通知伺服器該委託是否已經**獲,以決定是否需要繼續

raise

這個委託。這是本方案加入自定義委託捕獲的唯一途徑。

bool getenabled(object)

:返回是否需要向指定委託者發布。

有兩點需要說明:

一、示例未實現多介面,當然如果需要的話,改造過程非常簡單。

二、未處理帶返回值的方法的介面,當然如果需要的話,改造過程也非常簡單。

js 非同步解決方案

js的非同步請求歷來被詬病,但是社群和規範一直也在努力,這裡簡單說下這些變化。嚴格地說ajax屬於與伺服器交換資料的api,與非同步並不完全相同。但對於早期的前端來說,非同步的操作基本都是與ajax交涉的過程。可以看出這個物件具有濃濃的物件導向的風格,沒有函式式編輯的優雅。目前作為xhr的替代api...

nodejs的非同步呼叫

promise乙個標準,它描述了非同步呼叫的返回結果,包括正確返回結果和錯誤處理。關於詳細的說明文件可以參考promises a 目前實現promise標準的模組有很多,如q bluebird和deferred,下面我們以q為例,介紹一下promise在nodejs中的使用方法。我查詢了關於prom...

關於webservice的非同步呼叫簡單例項

關於webservice的非同步呼叫簡單例項 無論在任何情況下,被呼叫方的 無論是被非同步呼叫還是同步呼叫的情況下,被呼叫方的 都是一樣的,下面,我們就以非同步呼叫乙個webservice 為例作說明。這是乙個webservice public function delcurtable byval ...