我只是想进入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