健壯的自託管服務器的最佳選擇：WCF與ASP.NET Web Api

Question

我們目前有一個.NET 4應用程序，由後臺運行的Windows服務和本地或遠程客戶端（通常只有1-3個）組成。

客戶端有一個WPF GUI並需要來自Windows服務的一些數據。因此，我們使用帶有NamedPipe綁定的WCF作爲本地客戶端，並使用NetTcp綁定遠程客戶端。這有效，但我們經常遇到無法訪問的端點（通道故障或未找到等）的問題。我們已經嘗試重建故障連接，但它似乎很脆弱......

現在進入Web Api：它看起來像基於HTTP的堆棧可能更健壯（沒有通道，沒有端點，可以自行託管Windows服務）。似乎沒有問題，因爲每個請求都被單獨處理。所以如果某件事失敗了，你只需重複這個請求。 （而且我們有來自其他應用程序的ASP.NET MVC經驗，所以這對我們來說並不陌生）。

現在我們正在考慮什麼可能是我們最好的選擇。 「硬化」我們現有的WCF服務（一個約15個操作的服務接口）或將接口移動到Web Api並將它作爲HTTP請求（使用JSON數據）運行會更好嗎？性能不是我們這裏的主要問題...

任何想法？ Hartmut

Answer 1

我建議您堅持爲您的WPF應用程序使用WCF（SOAP）服務，而不是轉移到Web API。有許多的原因。首先，我認爲我們需要考慮新的Web API試圖解決什麼問題 - 即提供支持RESTful/HTTP /超媒體服務的框架。這可能非常適合構建大量使用HTTP的應用程序，如Web，移動和JavaScript應用程序，您希望最大限度地提高服務的「覆蓋範圍」或互操作性（與平臺無關）。這並不是說你不能將它用於WPF客戶端，但在你的情況下，所有的流量都是你的域的本地流量，堅持你當前的實現更合理。

您爲服務/客戶端所做的綁定選擇對我來說聽起來不錯。我會專注於爲什麼您的渠道出現問題並解決這些問題。您可能還想考慮通過IIS託管您的服務，並使用WAS來公開您的非HTTP端點。過去我已經取得了很大的成功，而且大部分都非常穩定。它還可以管理自己的主機，從而消除一些頭痛問題。如果您擔心TCP綁定錯誤，那麼只需創建一個新的HTTP或wsHTTP端點並使用它。這將爲您提供與web api完全相同的傳輸，而無需更改您的編程模型。