使用SignalR vs WCF将数据推送到客户端？

Question

我有一个WPF客户端 - 服务器应用程序。现在我有客户端将连接到服务器的场景，服务器将定期将数据推送到客户端。我对应该选择哪种技术和方式来通知客户感到困惑。

SignalR最适合我认为的Web应用程序，我有桌面应用程序。通过WCF服务，我们可以通过双工通道和回调实现推送通知。那么请您指导我使用SignalR或WCF服务的优点和缺点是什么？

由于

Answer 1

以下是我对经验的观察：

SignalR专业人士：

• 易于启动，降低学习曲线。您可以轻松运行从网络上找到的示例
• 异常处理（例如连接丢失，超时）嵌入在API
中

SignalR缺点：

• 仅支持HTTP协议

Duplex pros：

• 除HTTP之外还支持TCP。如果您了解客户端类型并且系统在封闭网络中工作，这可能会带来严重的性能提升。此外，通过TCP工作比HTTP
增加了更多的连接稳定性

Duplex cons：

• 更高的学习曲线 - 更难启动并拥有稳定的解决方案。想验证一下吗？从网上下载双工和SignalR样本，看看您将花多少时间成功相互运行。
• 您需要处理所有异常情况（连接丢失，超时等）
• 我知道当你想长时间使用双工服务时，我不是唯一一个遇到严重超时问题的人。我们需要定期进行服务调用以保持客户端连接的活跃。

顺便说一句，JavaScript，桌面和Silverlight项目都存在使用SignalR服务的API。

Answer 2

SignalR不只是关于网络。 SignalR服务器端代码不关心其客户端的技术，您只需要在客户端拥有实现者。

如果我们将pusing数据隔离到客户端，我强烈推荐SignalR，因为它在这方面比WCF简单得多，我在WCF中遇到了一些问题，我猜你自己也有一些问题。 我找到了一个简单的控制台/ Web应用程序示例here。

一般来说，Duplex WCF和像here一样使用Callback对我来说似乎非常混乱，配置服务器端很多，这就是为什么我认为SignalR更简单。

此外，您不能使用带有javascript和objective-c的双面打印（AFAIK）。

Answer 3

我认为你已经掌握了很多关于它们的数据。但选择SignalR将为您提供额外的优势，而不是开发工作，在大多数情况下，在选择技术时会出现重大决策障碍。

您无需担心API开发/测试等问题，并且可以专注于您自己的项目实施。

希望它有所帮助！

Answer 4

SignalR现在可以轻松地用于来自javascript，.NET WinForms和WPF的多个客户端，甚至可以与C ++客户端一起使用;使用自托管的.NET信号服务器（OWIN）是一种非常好的方法，可以将一个独立的服务器推送/接收/广播到多个客户端。唯一可能更容易的是ZeroMQ使用其发布订阅方法。

Answer 5

到目前为止没有人提出过一点：

• SignalR 1.0.1需要服务器和客户端上的.NET 4。取决于 您要定位的客户端和服务器的版本 可能是一个需要考虑的重要因素。

如果您只是想定期更新新数据，最好从客户端使用WCF和轮询机制，而不是使用双工WCF或信号器。