我只是想進入WCF;但從我迄今爲止閱讀的內容中可以看出，例如我在MSDN和其他網站上找到的示例場景，我可以用web services和調用這些Web服務的應用程序來完成所有這些。那麼爲什麼需要像WCF這樣的複雜圖層呢？WCF;有什麼大不了的？
大部分的比較我都是從編程的角度來解釋它。仍然試圖在沒有太多成功的情況下找到答案，以至於在何時使用WCF層而不是傳統的應用程序到Web服務模型進行業務，當然還有編程方面的意義。
任何人在這裏都有經驗，可以建議如何去選擇Web服務或去WCF的方式？那些無法完全使用應用程序調用的普通舊Web服務完成的事情，以及WCF層將保存一天的事情。
你愛上的微軟陷阱「它只是網絡服務」 :-)
它實際上很多更：
當然 - 這些東西大部分可以在ASMX或.NET遠程處理 - 但嘗試將ASMX Web服務轉換爲可調用在您的Intranet中使用TCP/IP和傳輸安全性......許多這些「舊」技術與他們如何使用它們有着非常複雜和直接的聯繫 - 在不更改整個服務代碼的情況下，您不能輕易更改。
WCF將所有這些「管道細節」分離出來，例如要調用哪個端點，使用什麼協議調用它，如何處理安全等，然後將其配置爲可組合的「WCF堆棧」，以便您輕鬆切換服務XYZ使用允許匿名用戶調用它的HTTP，使用需要Windows憑據的TCP/IP - 您的服務代碼不會改變 - 它只是管道配置。
這對我來說是WCF最引人注目的原因 - 我完全可以專注於我的實際服務代碼，並且不會污染大量管道工具 - 如何處理傳輸和文本編碼等等。而且，我可以輕鬆更改並適應部署中的新需求和需求，而無需觸摸我的實際服務代碼。
另外，第二個重點是可擴展性 - 大多數舊技術只有他們自己的一種設置方式，許多都不適用於擴展。你必須要麼按照他們的方式來使用它，要麼就忘了它。 WCF有一個龐大而複雜的系統來擴展幾乎任何東西 - 你可以創建自己的傳輸協議（人們已經創建了基於UDP或SMTP的綁定），你可以創建自己的消息編碼器（就像我必須做的與網絡交談服務只能理解ISO-8859-1編碼的消息），並且您可以擴展WCF中的其他任何內容 - 所有這些都是以有組織，記錄完備，非常穩定和安全的方式進行的。
因此，這兩件事情 - 將管道分解爲可配置的層，並且最大限度地擴展 - 是我使用WCF的最有說服力的理由。
編輯：上面的Kobi的link，是一個比我的好得多的答案。
WCF基本上是支持通信的更好的體系結構。它打破了諸如託管（不依賴iis），傳輸，安全性，尋址插件組件等許多依賴性，並且允許定製程度非常高。
是的，你可以用傳統技術做很多事情，但是你可以用WCF做更多的事情。如果您現在不需要這些功能，那麼您當然可以繼續使用傳統技術，但是如果您願意，現在可以選擇一個更好的架構，並着眼於未來，但現在需要花費不必要的技術。
以此爲例。如果您擁有傳統的asmx Web服務，您可以輕鬆地通過MSMQed端點提供相同的服務嗎？使用WCF就像添加新的配置設置一樣簡單。
我認爲你不是問「爲什麼不堅持使用SOAP/HTTP」。 WSF允許您選擇多種不同的傳輸方式，而不僅僅是簡單的HTTP方式，但正如您所看到的那樣，WS- *技術允許您執行所有這些操作。所以我認爲你問爲什麼在原始技術不可能非常複雜的情況下使用強大但複雜的框架？
你可以問任何框架的相同問題。你可以只使用基礎技術，避免採用框架的學習曲線。
框架，如WCF確實有一個學習曲線，但考慮到如果你不使用它們會發生什麼：
你發現你寫的每一個服務調用鍋爐板代碼。然後，您要麼接受重複，要麼開始重構並構建自己的庫。不久之後，您已經開發了自己的框架，但與其他人不一樣。那麼任何新的團隊成員都必須學習你的本地框架，認真學習。
還請注意，WCF解決諸如部署的解決方案的監視等問題。
對我的最大吸引力是testability。服務由CLR接口定義，很容易在測試工具中模擬。但是，有些警告的話。具有很大的靈活性會導致配置過程中的一些痛苦，以及一些「陷阱」。一個疑難問題的例子是WCF - 嚴格遵守「最佳實踐」 - 需要一個活動的SSL連接才能通過HTTP傳遞SOAP認證憑證。這阻礙了很多測試。
http://stackoverflow.com/questions/924756/what-am-i-missing-about-wcf – Kobi 2009-09-06 07:06:20