español - ¿Empujar datos al cliente usando SignalR contra WCF?
web api c# (5)
Tengo una aplicación de servidor de cliente WPF. Ahora tengo un escenario como el cliente se conectará al servidor y el servidor enviará datos al cliente periódicamente. Estoy un poco confundido acerca de qué tecnología y cómo debo elegir para notificar a los clientes.
SignalR es lo mejor para la aplicación web, creo, y tengo una aplicación de escritorio. Con el servicio WCF, podemos implementar la notificación de inserción a través del canal Duplex y la devolución de llamada. Entonces, ¿pueden por favor guiarme sobre cuáles son los méritos y deméritos al usar el servicio SignalR o WCF?
Gracias
A continuación están mis observaciones de experiencias:
Pros de SignalR:
- Fácil de iniciar, menor curva de aprendizaje. Puede ejecutar fácilmente un ejemplo encontrado desde la web
- El manejo de excepciones (por ejemplo, conexiones, tiempos de espera) está integrado dentro de la API
SignalR contras:
- Solo soporte de protocolo HTTP
Dúplex pros:
- Admite TCP además de HTTP. Esta puede ser una ganancia de rendimiento seria si conoce los tipos de su cliente y si su sistema funciona en una red cerrada. Además, trabajar con TCP agrega más estabilidad de conexión que HTTP
Contras dúplex:
- Curva de aprendizaje más alta: más difícil de iniciar y tener una solución estable. ¿Quieres verificarlo? Descargue un dúplex y una muestra de SignalR de la web y vea cuánto tiempo dedicará a funcionar correctamente entre sí.
- Debe manejar todos los casos excepcionales (caídas de conexión, tiempos de espera, etc.)
- Sé que no soy el único que se enfrentó a problemas graves de tiempo de espera cuando desea utilizar el servicio dúplex durante mucho tiempo. Necesitamos hacer llamadas de servicio periódicamente para mantener vivas las conexiones de los clientes.
Por cierto, existen API para proyectos de JavaScript, Desktop y Silverlight que consumen servicios de SignalR.
Creo que ya tienes muchos puntos de datos sobre cada uno de ellos. Pero la selección de SignalR le proporcionará una ventaja adicional sobre los esfuerzos de desarrollo, que en la mayoría de los casos es un bloque de decisión importante al seleccionar una tecnología.
No necesita preocuparse por el desarrollo / prueba de API, etc., y puede centrarse en su propia implementación del proyecto.
¡Espero eso ayude!
SignalR no es solo acerca de la web. El código del lado del servidor de SignalR no se preocupa por la tecnología de sus clientes, solo necesita tener implementadores en el lado del cliente.
Si aislamos los datos de pusing para el cliente, recomendaría fuertemente SignalR, ya que es mucho más simple que WCF en este aspecto, tuve mi parte de problemas con WCF y supongo que tenía algo usted mismo. Encontré una muestra simple de consola / aplicación web here .
En general, Duplex WCF y el uso de Callback como here parecen muy desordenados, hay una gran cantidad de servidores de configuración y es por eso que creo que SignalR es más simple.
Además, no puede usar dúplex (AFAIK) con javascript y object-c.
SignalR se puede usar ahora fácilmente con múltiples clientes de javascript, .NET, WinForms y WPF, e incluso se puede usar con un cliente C ++; El uso de un servidor de señalización .NET alojado en uno mismo (OWIN) es realmente una buena manera de tener un servidor independiente que empuje / reciba / difunda a múltiples clientes. Lo único que puede ser más fácil es ZeroMQ utilizando su metodología de publicación de suscripción.
Un punto que nadie ha planteado hasta ahora:
- SignalR 1.0.1 requiere .NET 4 en el servidor y el cliente. Dependiendo de la versión de su cliente y servidor al que apunta, ese podría ser un factor importante a considerar.
Si solo desea actualizar periódicamente los datos nuevos, es mejor usar simplemente WCF y un mecanismo de sondeo desde el lado del cliente en lugar de utilizar el WCF o el señalizador dúplex.