WCF;有什么大不了的？

Question

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

我用Google搜索的大部分比较都是从编程的角度解释它。仍然试图找到答案，但没有取得多大成功，关于什么时候开展业务，当然编程意义上使用WCF层而不是传统的应用程序到Web服务模型。

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

Answer 1

你已陷入微软陷阱“这只是关于网络服务”： - ）

实际上更多：

• 一般是关于面向服务的编程（不仅仅是Web服务 - 您还可以编写基于TCP / IP的服务，MSMQ基于队列的消息传递等等）
• 它是关于统一目前存在的所有各种编程模型（ASMX，Enterprise Services，DCOM，.NET远程处理）
• 它提供了大量现成的和随时可用的管道，它可以处理可靠的消息传递，事务支持，任何形状或形式的安全性，服务发现等，还有更多
• 它是关于将服务实现与客户端如何调用它的细节分开，并使其成为可配置的协议，编码堆栈等。

当然 - 大部分内容都可以在ASMX或.NET远程处理中完成 - 但尝试将ASMX Web服务转换为可在Intranet中使用TCP / IP和传输安全性进行调用...其中许多“较旧”技术与它们的使用方式有着非常复杂和直接的联系 - 如果不改变整个服务代码，就无法轻易改变它。

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

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

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

所以这两件事 - 将管道分为可配置层，并将可扩展性最大化 - 是我使用WCF的最有说服力的理由。

Answer 2

编辑：上面的Kobi link，是一个比我更好的答案。

WCF基本上是一种支持通信的更好架构。它打破了许多依赖关系，例如托管（不依赖于iis），传输，安全性，寻址到插件组件，并允许非常高的自定义。

是的，您可以使用传统技术做很多事情，但是您可以使用WCF做更多事情。如果您现在不需要这些功能，那么您当然可以继续使用传统技术，但是如果您愿意，现在可以选择更好的架构，着眼未来，但现在需要转换技术。

举个例子。如果您有传统的asmx Web服务，您可以通过MSMQed端点轻松提供相同的服务吗？使用WCF就像添加新的配置设置一样简单。

Answer 3

我认为你不是在问“为什么不坚持使用SOAP / HTTP”。 WSF允许您选择许多不同的传输而不仅仅是简单的HTTP，但是当您观察到WS- *技术允许您完成所有这些操作时。所以我认为你问为什么在原始技术不复杂的情况下使用强大而复杂的框架？

你可以问任何框架的同样问题。您可以使用基本技术，避免采用框架的学习曲线。

像WCF这样的框架确实有学习曲线，但考虑一下如果你不使用它们会发生什么：

您发现您为每个服务调用编写了样板代码。然后，您可以接受重复，也可以开始重构并构建自己的库。不久你就开发了自己的框架，但它与其他任何人都不一样。因此，任何新的团队成员都必须学习当地的框架，认真学习。

另请注意，WCF解决了部署解决方案的监控等问题。

Answer 4

对我来说最大的吸引力是testability。服务由CLR接口定义，在测试工具内部很容易模拟。但是，有些警告。具有很大的灵活性会带来一些配置过程中的痛苦，以及一些“陷阱”。一个问题的例子是WCF - 紧跟“最佳实践” - 需要一个活动的SSL连接才能通过HTTP传递SOAP身份验证凭据。这阻碍了测试。