example - signalr hub start
SignalR: ¿Por qué elegir Hub vs. Persistent Connection? (5)
Hay dos formas de usar SignalR: puede acceder a él en un nivel bajo sobrescribiendo su clase PersistentConnection , que le da mucho control sobre ella; o puede dejar que SignalR haga todo el trabajo pesado por usted, usando los ''Hubs'' de alto nivel.
He estado buscando y leyendo en SignalR recientemente y, aunque veo mucha explicación sobre la diferencia entre Hubs y Persistent Connections, no he podido entender el siguiente nivel, por lo que elegir un enfoque sobre el otro?
Hay tres puntos principales a considerar al comparar estos dos:
- Formato de mensaje
- Modelo de comunicación
- Personalización de SignalR
El formato de los mensajes de los concentradores se maneja básicamente por usted, pero con las conexiones constantes, el mensaje es crudo y se ha tokenizado y analizado de un lado a otro. Si el tamaño del mensaje es importante, también tenga en cuenta que la carga útil de una conexión persistente es mucho menor que la de un concentrador.
Cuando se trata del modelo de comunicación, las conexiones persistentes básicamente tienen una función para enviar y recibir mensajes mientras que los concentradores toman un modelo de llamada de procedimiento remoto con función única por requerimiento.
Cuando se trata de personalización, dado que las conexiones persistentes tienen un nivel más bajo, pueden darle más control sobre la personalización.
La conexión persistente es una API de nivel inferior, puede realizar acciones en un momento más específico cuando la conexión se abre o cierra, en la mayoría de las aplicaciones, el concentrador es la mejor opción.
La principal diferencia es que no puede hacer RPC con PersistentConnection, solo puede enviar datos brutos. Entonces, en lugar de enviar mensajes del servidor como este
Clients.All.addNewMessageToPage(name, message);
Tendría que enviar un objeto con Connection.Broadcast() o Connection.Send() y luego el cliente tendría que decidir qué hacer con eso. Podría, por ejemplo, enviar un objeto como este:
Connection.Broadcast(new {
method: "addNewMessageToPage",
name: "Albert",
message: "Hello"
});
Y en el cliente, en lugar de simplemente definir
yourHub.client.addNewMessageToPage = function(name, message) {
// things and stuff
};
Tendría que agregar una devolución de llamada para manejar todos los mensajes entrantes:
function addNewMessageToPage(name, message) {
// things and stuff
}
connection.received(function (data) {
var method = data.method;
window[method](data.name, data.message);
});
Tendría que hacer el mismo tipo de despacho en el lado del servidor en el método OnReceived . También debería deserializar la cadena de datos allí en lugar de recibir los objetos fuertemente tipados como lo hace con los métodos concentradores.
No hay muchas razones para elegir PersistentConnection en Hubs. Una razón por la que estoy enterado es que es posible enviar JSON preserializado a través de PersistentConnection, lo que no se puede hacer usando concentradores. En ciertas situaciones, esto podría ser un beneficio de rendimiento relevante.
Aparte de eso, vea esta cita de la documentation :
Elegir un modelo de comunicación
La mayoría de las aplicaciones deberían usar la API Hubs. La API de Connections podría usarse en las siguientes circunstancias:
El formato del mensaje real enviado necesita ser especificado.
El desarrollador prefiere trabajar con un modelo de mensajería y despacho en lugar de un modelo de invocación remota.
- Una aplicación existente que usa un modelo de mensajería está siendo portada para usar SignalR.
Dependiendo de la estructura de su mensaje, también puede obtener pequeños beneficios de rendimiento al usar PersistentConnection.
Es posible que desee echar un vistazo a las muestras SignalR, específicamente aquí.
Según lo que veo en la sección Conexión y Hubs, parece que los Hubs proporcionan un sistema de temas que se superpone a las conexiones persistentes de nivel inferior.
Del comentario altamente votado a continuación:
Parcialmente correcto. También puede obtener temas o grupos en conexiones persistentes. La gran diferencia es enviar diferentes tipos de mensajes. Por ejemplo, tiene diferentes tipos de mensajes y desea enviar diferentes tipos de cargas útiles. Con las conexiones persistentes, debe incrustar el tipo de mensaje en la carga (ver ejemplo sin procesar), pero los concentradores le dan la capacidad de hacer RPC a través de una conexión (le permite invocar métodos en el cliente desde el servidor y desde el servidor al cliente) . Otra gran cosa es el modelo de encuadernación. Los concentradores le permiten pasar parámetros fuertemente tipados a los métodos.
El ejemplo utilizado en la documentación utiliza una metáfora de la sala de chat, donde los usuarios pueden unirse a una sala específica y luego solo recibir mensajes de otros usuarios en la misma sala. De manera más genérica, su código se suscribe a un tema y luego solo recibe los mensajes publicados sobre ese tema. Con las conexiones persistentes obtendrías todos los mensajes.
Podrías construir fácilmente tu propio sistema de temas sobre las conexiones persistentes, pero en este caso el equipo de SignalR ya hizo el trabajo por ti.