SignalR: ¿Por qué elegir Hub vs. Conexión persistente?

He estado buscando y leyendo sobre SignalR recientemente y, aunque veo muchas explicaciones sobre cuál es la diferencia entre los Hubs y las Conexiones persistentes, no he podido entender el siguiente nivel, por lo que debería elegir un enfoque sobre el otro?

Por lo que veo en la sección Conexión y Hubs, parece que los Hubs proporcionan un sistema de temas que superpone 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. Con conexiones persistentes, debe incrustar el tipo de mensaje en la carga útil (consulte la muestra sin formato), pero los concentradores le permiten realizar 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. Más genéricamente, su código se suscribe a un tema y luego solo recibe mensajes publicados sobre ese tema. Con las conexiones persistentes obtendrías todos los mensajes.

Puede crear fácilmente su propio sistema de temas sobre las conexiones persistentes, pero en este caso el equipo de SignalR ya hizo el trabajo por usted.

La principal diferencia es que no puede hacer RPC con PersistentConnection, solo puede enviar datos sin procesar. Entonces, en lugar de enviar mensajes desde el servidor como este

Clients.All.addNewMessageToPage(name, message);

tendrías 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 OnReceivedmétodo. También tendría que deserializar la cadena de datos allí en lugar de recibir los objetos fuertemente tipados como lo hace con los métodos de concentrador.

No hay muchas razones para elegir PersistentConnection sobre Hubs. Una de las razones por las que estoy al tanto es que es posible enviar JSON preerializados a través de PersistentConnection, lo que no se puede hacer con los concentradores. En ciertas situaciones, esto podría ser un beneficio de rendimiento relevante.

Aparte de eso, vea esta cita de la documentación :

Elegir un modelo de comunicación

La mayoría de las aplicaciones deberían usar la API de Hubs. La API de Connections podría usarse en las siguientes circunstancias:

• El formato del mensaje real enviado debe especificarse.

• 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 de SignalR, específicamente esto aquí.

Hay dos formas de usar SignalR: puede acceder a él en un nivel bajo anulando su PersistentConnectionclase, lo que le da mucho control sobre él; o puede dejar que SignalR haga todo el trabajo pesado por usted, utilizando los 'Hubs' de alto nivel.

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 se cierra, en la mayoría de las aplicaciones, el Hub es la mejor opción

Hay tres puntos principales a considerar al comparar estos dos:

• Formato de mensaje
• Modelo de comunicación
• Personalización de SignalR

Con el formato de mensajes de los concentradores, básicamente se maneja desde usted, pero con conexiones persistentes, el mensaje es sin formato 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 a procedimiento remoto con una función única por requerimiento.

Cuando se trata de personalización, ya que las conexiones persistentes tienen un nivel más bajo, pueden darle más control sobre la personalización.