我应该使用双工WCF服务还是常规WCF服务？

Question

我目前正在开发一个C＃Windows窗体应用程序，我打算让它与服务器进行交互。服务器将从我开发的移动应用程序接收发布，每当收到发布时，我的Windows窗体应用程序都会收到通知并给我通知。

E.g。我的移动应用程序将帖子发送到我的服务器。一旦我的服务器收到消息，我的Windows窗体应用程序应显示一条新通知，显示收到的消息内容并相应地更新UI。

在这种情况下，最好使用双工WCF服务还是仅使用常规WCF服务？

如果是双工，请注意解释为什么我需要使用双工服务？谢谢！

Answer 1

双工服务是一种创建两个通道的服务。

• 第一个渠道是普通客户 - ＆gt;服务器频道使用您的服务合同。这是您在每个 WCF服务中可以找到的内容，也是您的客户端可以向服务发送请求并且可以响应的方式。
• 第二个频道是服务器 - ＆gt;客户端通道使用您定义的其他服务合同。第二个渠道是服务器如何在没有客户请求的情况下向客户端发送消息。

在您的方案中，您似乎表明服务器上发生的事件应该向您的客户发送消息。如果是这种情况，那么是的，您需要双工服务，以便存在第二个通道，这允许服务器在客户端未发起请求的情况下通知您的客户端。

Answer 2

假设您的Windows应用程序和服务器属于同一个域，我建议您使用发布/订阅模式进行此类交互。您可以使用其网站上提供的IDesign sample行内容。基本上，您的Windows应用程序正在订阅由您的移动应用程序发送到您的服务器的帖子生成的事件。然后，您的发布者会将该事件推送到您的Windows应用程序。

要实现此目的，您需要始终打开与服务器/发布者的连接。这最好通过tcpBinding实现，因为它是双向的，允许您设置高超时（实际上是无穷大）。

如果你不能使用TCP那么你的工作就变得有点难了。使用双工通道有点问题，因为您还必须监控通道，因为如果通道关闭，任何一方都不会通知另一方。您只会在尝试使用它时找到它。当然，TCP连接仍然会发生这种情况，但使用http。

会更稳定

另一种选择是使用MSMQ绑定。这将保证您的消息的传递，因为您通过MSMQ而不是通信渠道（如http或tcp）进行交互。在这种情况下，您甚至不需要pub / sub框架，您可以将接收移动发布的服务发送到队列中的消息，Windows应用程序正在监视该队列。使用该框架的好处是，您可以让多个应用程序监听同一事件。

HTH。