使用Signalr的优缺点是什么
当然,除非你需要它所提供,这是说,一个简单的,复式的Web服务层专注于JavaScript客户端,你不应该使用SignalR。如果您是全新的ASP.NET,那可能不是您将立即需要的东西 - 在开始编写复杂的,数据驱动的JavaScript应用程序之前,您还有很多其他东西需要学习。如果你只是要使用.NET客户端,那么坚持使用WCF:它更加灵活,并且它的静态类型更适合于C#和VB.NET。
也就是说,当你在做需要一个基于.NET的web服务后端的JavaScript应用程序时,SignalR是一个不错的选择。它比Windows Communication Foundation配置简单得多,对于JavaScript应用程序,它具有更好的功能。它似乎是由微软赞助的(他们允许它坐在微软的.AspNet命名空间中),负责它的人似乎很聪明,而且工作非常努力(如果时间有点匆忙)。我曾经在午夜报告了一个错误,在15分钟内做出了回应,并且在我早上起床时得到了修复。当然,它是开源的,他们愿意考虑拉取请求,所以如果你需要修复某些东西,那么与微软以前的闭源模型相比,你会有更好的运气。
它唯一真正的缺点是它非常新 - 它最近达到1.0 RC1状态 - 因此缺少一些很好的功能,并且仍然有一些错误(当然这些错误最终会得到修复)。
下面是一个它如何还是有点新的例子。如果你试图序列化复杂的对象图,那么你几乎肯定会碰到的一个问题是,它使用Json.NET的专有格式来进行对象引用,所以最终会出现很多像这样的JSON:
{
"$id": "57",
"Name": "_default",
"User": {
"$id": "58",
"UserTag": "ken",
"Sessions": [{
"$id": "59",
"SessionId": "0ca7474e-273c-4eb2-a0c1-1eba2f1a711c",
"User": {
"$ref": "58"
},
"Room": {
"$ref": "57"
}
}],
},
"Sessions": [{
"$ref": "59"
}]
}
这是不是非常有帮助的阅读Session[]
阵列,并且发现在它的唯一对象不是Session
可言,但有一个单一的$ref
属性的任意对象。为了解决这个问题,你需要用JsonNetDecycle这样的东西来包装所有的SignalR电话。并不困难,但是在SignalR本身中处理会很好。 (当然,如果我是一个更好的人,我会自己编写代码并提交它作为一个拉请求 - 只是还没有得到它。)
在什么意义上与什么相比? –
问题如果对于像我这样新手的人来说完全没问题的话,只有真正的开发人员才能说出这件事,用这种方法,他们肯定已经完成了其他任何事情 –