为了我的理解,SignalR通过使用Web Sockets对实时Web应用程序是有好处的.而通知中心可以轻松地在多个平台上发送推送通知.
为了方便您的回应,我可以解释一下我目前拥有的结构以及应用程序的应用.
应用程式：
它基本上是一个应用程序,用户可以创建组并邀请其他用户.用户还可以使一个组“在线”,以便其他用户可以“输入”组.当组在线并且用户已经输入时,他们可以发送问题,交换消息等.
需求：
当用户在组中提出问题,或者进入/离开组时,其他用户需要在应用屏幕中看到新用户.我可以在服务器上进行轮询来检查并更新UI,但这是现代时代所不允许的.我在这个问题上的搜索引起了两件事：SignalR和NotificationHub.
目前的架构：
客户端 – > PhoneGap应用程序与backbone.js.
后端 – > Asp.NET Web API与实体框架和Azure Sql Server.
我已经考虑使用通知中心和标签.
例如,当用户输入在线组时,它向服务器发送一个请求以注册“grouplisten：{groupId}”标签.然后,服务器将该标签注册到用户的设备,并且还通过标签“grouplisten：{groupId}”向所有其他设备发出通知,以便其他用户使用最近加入的用户更新用户界面.此外,当用户离开组时,它会向服务器发送一个请求,以删除“grouplisten：{groupId}”标签,并通知“grouplisten：{groupId}”的设备.但是通过这个简单的例子,看起来像这样可以变得难以管理.
SignalR
优点：
>非常适合实时交付,时间或从服务器接收通知很重要.
>所有主流浏览器,IE8,FireFox,Chrome,Safari和Android WebView,iOS Safari,IE手机均支持Web客户端,因此它们运行良好.
>解决方案可以用JS编写,无需知道
缺点：
>必需的专用服务器,但可能托管与共享托管可能,因为没有性能饿了.
> Cordova特别需要手动连接管理,以获得更好的用户体验,而不是依靠SignalR提供的重新连接机制(这对于iOS而言可能会丢失网络连接以进行电池维护,在Android上是不需要的).
>它具有Safari在iOS上的一个已知问题(需要运行长轮询配置,you can find more on that issue here) – 在具有频繁ajax请求的现实世界场景中,强制您使用不同的IP地址进行SignalR Server的无缝体验iOS版.
Azure通知中心
优点：
>使用Google,Apple和MS的现有基础架构向用户发送通知,并且每个用户都不保证立即交付通知.您必须分别阅读每个平台：
>苹果：Quality Service section of APNS docs
> Google：GCM Advanced Topics
>不需要专用服务器
缺点：
>不保证立即发货.
>需要使用每个本机平台的语言. (Cordova https://github.com/sgrebnov/cordova-plugin-azure-notificationhub的插件很棒,但是当Android上的应用程序暂停并且iOS上没有64位版本时,它不允许收到通知)