於先前小節內容，引用微軟的圖:

說明利用事件驅動應用有很大的好處。事件驅動可以使用觀察者模式進行類似的描述和比較， 一般來說，執行什麼動作和觸發事件同時進行即時通知，可以達到Real Time的效果。

大多數傳統的方法是輪詢，它不斷地讓系統花費資源來獲得要執行的目的。 事件驅動則相反，可以讓系統處於空閒狀態，當真正有需求時，會真正花費系統資源處理，因此可以節省資源，有效利用資源。 未來的系統應該能夠與此概念一起廣泛使用，以實現未來的需求。

我們可以使用Queue來達到即時通知的效果，達到Event-driven Real-Time的目的。

一個簡單的例子用來模擬事件驅動。 首先，我們將使用 Rabbit MQ 來展示，然後使用自製的 Queue 類別來實現。 不管用什麼 Component 來實現，還是要注意發送到 Queue 中的對像是否足夠重要，不會憑空消失，或者斷電斷電後數據是否丟失 恢復了，好像什麼都沒有發生。 您可以通過兩種方式開始：

1. QUEUE或其他實現的組件具有滿足支持要求的管理模型。
2. 如果發送對象的過程失敗，可以有重新發送機制。

事實上，上述配套設施都有其複雜性，因此首先提出來考慮。 這裡我們主要展示基本的實現。
簡單的設計概念圖如下：

RabbitMQ 可以換成其他的 QUEUE，或者其他可以立即通知的組件。

實現一個簡單的 Rabbit MQ 示例，如下：

首先創建一API 放置操作。

立即在建立後端接收事件驅動的 Rabbit MQueue。

接下來就是實作了，使用HTTP Request發送API，本例依次印出三個數據，後台會立即發現數據發送到Rabbit MQ，觸發相應事件。

這裡的事件是取出後顯示內容。

通過Queue進行事件驅動的中介驅動非常簡單方便。 但是，正如前提中提到的，仍然需要考慮匹配。
如果在很簡單的情況下，只想展示一個中間驅動，也可以自己自定義一個組件，然後繼續填寫配套組件。

下面是一個簡單示例，用於演示使用 .NET 模擬 Queue 對象的中介驅動程序。 首先是類別：

接著是API:

最後是執行情況。 發送到QUEUE後，觸發事件印出訊息。

通過一個簡單的例子來體驗一下Event-driven是怎麼回事，理解之後還是需要其它適合的配套才能完善整個管理。