打一個WCF服務

Question

可能重複之前增加一個檢查：
WCF API Deployment Versioning

我在WCF REST服務工作。我有幾項服務。 現在，在客戶端訪問服務之前，我想添加一個檢查即viz。一個版本號。 如果版本號小於2.0，那麼客戶端應用程序應該會收到一個錯誤「應用程序已過期」，並且它不應該觸發該服務。

我的主要目的是，我不想在每個web服務中應用此檢查。我想要一些通用的服務，首先檢查版本，然後只允許客戶端點擊所需的服務。

這是怎麼做到的。 此外，這是否可以在.NET中的經典Web服務中使用。

Answer 1

我覺得這是一個非常糟糕的主意 - 你需要創建這在某種程度上知道你所有的服務端點的所有版本的詳細信息的集中服務，然後要求你的消費者做出的額外調用，以消耗您服務。

這就造成故障在單個點，如果該「版本檢查」服務不可用，那麼「有效」的消費者（那些用正確的客戶端版本）仍然將無法打電話給你的服務。你

也需要在這個中心位置，它產生支持成本，以保持每個服務的當前版本。

versionning您服務的最好辦法是嘗試讓非斷的變化，使老版本的客戶端可以支持。你在很多方面都這樣做。我之前在here和here之前發佈過這個消息。

如果必須進行重大更改，則說明您需要讓消費者打破（並因此被迫升級），或在不同的端點您共同主辦不同版本的服務。

備註：有些東西是針對您的想法設計的，稱爲UDDI。 UDDI服務器背後的想法是，它可以存儲有關服務的所有信息，包括端點地址，傳輸，甚至是公開的類型，以便消費者可以在運行時查詢UDDI並即時組裝客戶端。

這將導致你的消費者需要絕對沒有你的服務版本的知識可言，並且將檢索從UDDI運行時，這個信息。

但是很少使用UDDI（可能出於同樣的原因，它引入了單點故障）。當我爲客戶構建ESB時，我在我的職業生涯中只使用過它一次。

編輯

在回答您的意見，我想你最好的解決辦法是暴露出版本成員對你的服務操作請求合同類型這就需要消費者申報服務的哪個版本他們期待打電話。

收到請求後，您可以詢問請求並檢查版本。如果它們不匹配，則可以拋出在FaultContract中定義的類型的異常。 （更多關於故障合同here）。

這將使您的消費者能夠將服務操作調用包裝在catch塊中，並處理傳回的自定義異常類型。我不認爲有任何涵蓋「無效版本」錯誤的內置例外，因此您需要定義自己的錯誤。

這意味着消費者只會在嘗試使用過期的版本屬性調用服務時收到異常，並且無需再進行額外的服務調用。它也分發這些信息而不是集中它（這是更強大的方法）。

EDIT 2

在回答您的意見，故障合同不ASMX支持。你將不得不拋出異常的服務，然後在客戶端捕獲異常作爲SoapException。在客戶端上，您必須查詢SoapException消息（不太好）才能確定是否因爲版本控制。