使用WCF替換TCP/IP管道

Question

因此，目前我的公司正在使用TCP/IP連接在服務器和客戶端程序之間進行通信，現在我們正在使用System.RunTime.Remoting建立此連接，該連接笨重且不可靠。它建於大約5年前，模型不斷重複使用，它開始傳播一些問題，使用的端口，拒絕連接等。

我想找到一些資源，如何將此更改爲WCF但我不確定我在找什麼或者我應該搜索什麼。

如果您想了解更多關於實際操作的信息，我可以詳細介紹一下，但我需要拉起代碼並確保完整地解釋它。

謝謝！

Answer 1

Mikael已經在他的帖子中提到了大多數相關的問題 - 選擇了netTcpBinding，它非常快速，在局域網環境中工作得非常好，並且具備了您應該需要的所有功能。

主要區別在於思維方式的改變：在遠程處理中，基本上使用「遠程對象」 - 您或多或少地遠程控制另一臺計算機上的現有.NET對象。從根本上說：WCF有一個服務器和一個客戶端，它們除了服務契約（方法描述）和數據契約（對數據傳遞的描述）之外沒有其他的共享。在運行時，您調用客戶端上的代理，WCF運行時攔截該調用，將其序列化（包括所有參數），然後通過線路發送序列化消息（在netTcpBinding的情況下爲二進制串行化）。

另一端的服務器有一個運行時組件，它監聽這些消息，並將它們從線路中剔除，解開它們，然後調用服務實例來運行您想要的方法。

最重要的部分是：它是一個基於消息系統 - 除了（XML模式表示服務接口和數據結構）的合同，你有在運行時，雙方之間沒有連接。

這也意味着：有沒有辦法爲服務器「回到」客戶端，並找出一些東西或要求更多的信息。所有服務必須處理的是您（或WCF運行時）可能發送的消息和任何潛在的消息頭。而已。另外：由於數據交換是通過序列化消息進行的，並且需要符合XML模式標準，所以不能使用類似接口或泛型的東西 - 只能傳遞類的具體實例。

因此，總而言之 - WCF在某種程度上取代了.NET的遠程處理 - 但在某些方面，它是一個完全不同的野獸。這有利有弊，但你只需要意識到這些差異，不要試圖與他們作鬥爭 - 要麼你可以安排自己並從中受益，或者不要使用WCF在你的工作手。

Answer 2

有一個古老的，但很好的文章，稱爲「Migrating .NET Remoting to WCF (and even ASMX!)」，你應該看看。

我自己做了大量的遠程處理，並且在封閉的環境中，我仍然認爲它有它的位置。特別是當速度令人擔憂時。 （我必須有點不同意遠程處理是不可靠的。對於局域網通信我沒有任何問題。）

我更喜歡WCF的是你必須創建你的代理對象，然後運行調用。您可以更容易地看到您正在進行遠程通話。 Remoting有點隱藏了這個imo。

要注意的一件事是，通過WCF設置事件比通過遠程處理設置事件更多的工作，但這是一個小的代價。一旦你瞭解了WCF以及如何針對你的特定場景優化配置，你將不會回頭。它比遠程處理更靈活，可以在更遠的距離使用，遠程處理並不是太好（根據我的經驗）。

一定要在WCF中爲您的需要選擇一個傳輸通道，即tcp，命名管道或肥皂。