WCF; 有什么大不了的？

我只是想进入WCF ; 但是从我到目前为止所读到的内容来看,就像我在MSDN和其他一些网站上找到的示例场景一样,我可以通过调用这些Web服务的Web服务和应用程序来完成所有这些操作.那么为什么需要像WCF那样精心设计的层？

我用Google搜索的大部分比较都是从编程的角度来解释它.仍然试图找到答案,但没有取得太大成功,何时它使业务和编程意义上使用WCF层而不是传统的应用程序到Web服务模型.

这里有两方面经验的人可以就如何选择网络服务或采用WCF方式提出建议吗？什么是使用应用程序调用的普通旧Web服务以及WCF层将节省时间的绝对不能完成的事情.

你已经陷入了微软陷阱"这只是关于网络服务":-)

它实际上更多:

它是关于面向服务的编程(不仅仅是Web服务 - 您还可以编写基于TCP/IP的服务,基于MSMQ队列的消息传递等等)

它是关于统一迄今为止存在的所有不同编程模型(ASMX,企业服务,DCOM,.NET远程处理)

它是关于提供大量现成的和随时可用的管道,可以处理可靠的消息传递,事务支持,任何形状或形式的安全性,服务发现等等.

它是关于将服务实现与客户端如何调用它的细节分开,并使其成为可配置的协议,编码等堆栈.

当然 - 大多数这些东西都可以在ASMX或.NET远程处理中完成 - 但尝试将ASMX Web服务转换为使用TCP/IP和传输安全性在您的Intranet中可调用...许多"旧"技术都有非常复杂和直接的链接到它们的使用方式 - 如果不改变整个服务代码,你就无法轻易改变它.

WCF将所有这些"管道细节"分开,例如要调用的端点,用于调用它的协议,如何处理安全性等,以及可配置和可组合的"WCF堆栈",以便您可以轻松切换服务XYZ以便使用HTTP允许匿名用户调用它,使用需要Windows凭据的TCP/IP - 您的服务代码不会改变 - 它只是管道的配置.

这对我来说是WCF最引人注目的原因 - 我可以完全专注于我的实际服务代码,而不是用大量的管道事件污染它 - 如何处理传输和文本编码等等.我可以轻松地更改它并适应部署中的新要求和需求,而无需触及我的实际服务代码.

此外,第二个要点是可扩展性 - 大多数旧技术只有它们的一种,设定了做事的方式,许多不适合扩展.你不得不适应它们的方式使用它 - 或者忘掉它.WCF有一个庞大且非常复杂的系统,几乎可以扩展任何东西 - 你可以创建自己的传输协议(人们已经创建了基于UDP或SMTP的绑定),你可以创建自己的消息编码器(就像我必须做的那样与网络通信)只能理解ISO-8859-1编码消息的服务,你可以扩展WCF中的任何其他东西 - 所有这些都是有组织的,记录良好,非常稳定和安全的方式.

所以这两件事 - 将管道分成可配置的层,以及最大程度的可扩展性 - 是我使用WCF的最有说服力的理由.