最佳實踐？等到收到或提出收到活動

Question

首先，我想感謝社區。你最近一直很支持！通常我甚至不需要提問，因爲他們已經在那裏了。現在我有一個與代碼沒有直接關係的問題，但是編程本身。

我正在使用一個FTDI芯片和C＃編程的通信協議，其中PC應用程序的行爲像主人（將發送請求），也有奴隸設備誰會回答他們，不是立即，也許是一對夫婦毫秒，但無論如何，需要一段時間。我陷入了一個概念/哲學的代碼設計問題。

發送請求後，應我要求馬上一個答案（也檢查超時），或者我應該不斷地監視輸入（BackgroundWorker的供電）和接收數據輸入後，引發事件？你會推薦什麼，你的體驗如何。我應該考慮什麼因素來做出我的選擇？

我沒學過編程本身，所以我想我沒有這個基本的軟件設計，但這是一個個人項目我工作和肯定，我很樂意/這個指針從你們的一些反饋。

謝謝！

Answer 1

在這種情況下，我的首選解決方案是在異步模式下發出請求（例如，當它完成時觸發一個事件，然後觸發），並使用標準的.Net機制實現異步超時如果看起來從站沒有響應，則回叫您。這樣你就可以開始請求和計時器，然後可以繼續做更多的工作，而不需要任何其他線程來處理結果。

你必須確保並響應到達同時發生的時乾淨地使用鎖定機制，這樣你肯定知道你是否超時或處理的響應處理。

儘量避免輪詢和輸入監控，除非你的奴隸的API不允許確定性生成響應事件。

Answer 2

通常我會在低級別網站上使用異步方法，並且可能會在此之上放置一些同步機制。下面是一些示例方法，如果您獲取數據片段，並且必須將這些片段組合成一個完整的消息。

所以在低級別的網站實現不停地檢查輸入數據一個BackgroundWorker和提高某種事件，如果你得到的東西，並把這個到事件。

以上這是有人聽傳入數據的事件，並把所有這些（也許）片段到內部隊列中。在那裏它檢查它是否已經有足夠的數據完成一條消息，也許會進行一些錯誤檢查等。如果它有一個完整的消息，它會引發一個事件，把這個消息發送給那裏的所有監聽者。

最重要的是讓另一個類來監視消息並對它們做出反應。這個類可能實現了一些同步機制來監視傳入消息是否匹配事先應該發生的事情。

我認爲這種設計可以讓您更輕鬆地對不希望發生的事情發生的數據作出反應。當你喜歡關閉時，你不必等待任何超時發生（可能是BackgroundWorker低級別用來將數據從不支持事件機制的源中拉出）的非常小的超時發生。