一門好的語言它就要有一定的設(shè)計模式，在WCF這門技術(shù)中它也提供了許多種設(shè)計模式，有了設(shè)計模式在我們的應(yīng)用中就會很方便，我們這里就WCF設(shè)計模式中的發(fā)布-訂閱模式分析一下吧。針對事件使用原來的雙向回調(diào)通常會引入發(fā)布者與訂閱者的高度耦合。訂閱者必須知道所有發(fā)布的服務(wù)在應(yīng)用程序的位置，并連接它們。訂閱者不能識別的發(fā)布者無法通知事件的訂閱者。如果增加新的訂閱者（或者移除已經(jīng)存在的訂閱者）就會給已經(jīng)部署了的應(yīng)用程序帶來困難。

#T#無論什么時候，對于應(yīng)用程序的任何人發(fā)出的事件的一個特定類型，訂閱者都無法要求獲得通知。此外，訂閱者必須為每個發(fā)布者發(fā)出多個昂貴的調(diào)用，不管是訂閱還是取消訂閱。不同的發(fā)布者可能會觸發(fā)相同的事件，但卻為訂閱者和取消訂閱提供了略微不同的方法，自然而然給訂閱者與相關(guān)方法帶來耦合。大致相同的是，發(fā)布者只能通知它知道的訂閱者。無論是誰，如果希望接收事件，發(fā)布者都無法將消息傳遞給它，也沒有能力廣播事件。此外，所有的發(fā)布者都必須包含必要的代碼，管理訂閱者列表以及自身的發(fā)布行為。這些代碼幾乎與服務(wù)要解決的業(yè)務(wù)問題無關(guān)，如果還要提供一些高級特性，例如并發(fā)發(fā)布，就會增加相當大的復(fù)雜度。

而且，基于雙向的回調(diào)同樣會引入發(fā)布者與訂閱者生命周期的耦合度。為了訂閱和接收事件，必須運行訂閱者。訂閱者無法詢問事件是否被觸發(fā)，而應(yīng)用程序則需要創(chuàng)建一個訂閱者的實例，讓它處理該事件。安全性則代表了另外一種耦合：訂閱者需要通過各種安全模式以及使用的證書，以具備驗證所有發(fā)布者的能力。同時，發(fā)布者也需要具有足夠的安全證書，從而允許觸發(fā)事件，不同的發(fā)布者可能具有不同的角色成員機制。

最后，必須以編程方式設(shè)置訂閱信息。我們很難通過管理方式在應(yīng)用程序中配置訂閱信息，或者在系統(tǒng)運行時，改變訂閱者的選項。這些問題實際上不是WCF雙向調(diào)用所特有的，過去的技術(shù)例如COM連接點或者.NET委托同樣具有這樣的特性。所有這些都屬于緊密耦合的事件管理機制。

WCF設(shè)計模式發(fā)布-訂閱

若要解決以上提及的問題，可以使用已知的發(fā)布-訂閱設(shè)計模式對它們進行設(shè)計。該模式所隱藏的含義很簡單：通過引入一個專門的訂閱服務(wù)，以及一個專門的發(fā)布服務(wù)，解除發(fā)布者與訂閱者之間的耦合，如圖所示。

 
   
 
圖一個發(fā)布-訂閱系統(tǒng)

需要訂閱事件的訂閱者注冊訂閱服務(wù)，該服務(wù)負責(zé)管理訂閱者列表，同時為取消訂閱提供了相似的功能。同樣，所有發(fā)布者均使用發(fā)布服務(wù)觸發(fā)它們的事件，避免將事件直接傳遞給訂閱者。訂閱和發(fā)布服務(wù)提供了一個間接層，從而解除了與系統(tǒng)之間的耦合。訂閱者不需要了解發(fā)布者的身份。它們能夠訂閱事件類型，以及接收任何發(fā)布者的事件，并且訂閱機制對于所有訂閱者都是統(tǒng)一的。事實上，發(fā)布者不需要管理任何訂閱列表，也不用關(guān)心訂閱者是誰。它們會將事件傳遞給發(fā)布服務(wù)，然后再傳遞給需要事件的訂閱者，上述就是一個WCF設(shè)計模式的一個簡單介紹。