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 próximo nivel, por lo que ¿Elegiría un enfoque sobre el otro?SignalR: ¿Por qué elegir Hub vs. Persistent Connection?
Según lo que veo en el Connection and Hubs section, parece que los concentradores proporcionan un sistema de temas que se superpone a las conexiones persistentes de nivel inferior.
Desde el comentario muy arriba-abajo votado:
parcialmente correcta. 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 sala de chat, donde los usuarios pueden unirse a una habitación específica y luego recibir mensajes de otros usuarios en la misma habitación. 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.
Puede construir 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.
Existen dos formas de usar SignalR: puede acceder a él en un nivel bajo anulando su clase PersistentConnection, lo que le da mucho control sobre él; o puede dejar que SignalR haga todo el trabajo pesado por usted, usando los 'Hubs' de alto nivel.
respuesta simple y clara :-) – WASIF
conexión persistente es una API de nivel inferior, puede realizar acciones en el tiempo más específico cuando se abre o se cierra la conexión, en la mayoría de las aplicaciones, el Hub es la mejor opción
La principal diferencia es que no se puede haga RPC con PersistentConnection, solo puede enviar datos brutos. Así que en lugar de enviar mensajes desde el servidor de esta
Clients.All.addNewMessageToPage(name, message);
que lo tienes que enviar un objeto con Connection.Broadcast() o Connection.Send() y luego el cliente tendría que decidir qué hacer con eso. Se podría, por ejemplo, enviar un objeto como éste:
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
};
usted tendría que añadir 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);
});
Habría que hacer el mismo tipo de despachar 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 over Hubs.Una razón por la que soy consciente es que es posible send preserialized JSON a través de PersistentConnection, lo cual no se puede hacer usando concentradores. En ciertas situaciones, esto podría ser un beneficio de rendimiento relevante.
Aparte de eso, ver esta cita del documentation:
La elección de un modelo de comunicación
mayoría de las aplicaciones deben utilizar la API de concentradores. La API de conexiones podría ser utilizado en las siguientes circunstancias:
El formato del mensaje real enviado necesidades que ha de fijar.
El desarrollador prefiere trabajar con un modelo de envío y envío de mensajes 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 del mensaje, también puede obtener pequeños beneficios del perfomance del uso de PersistentConnection.
Es posible que desee echar un vistazo a las muestras SignalR, específicamente this here.
Hay tres puntos importantes a considerar cuando se comparan estos dos:
Con hubs me El formato del documento se maneja básicamente de usted, pero con conexiones persistentes, el mensaje está en bruto 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 remote procedure call 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.
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. – davidfowl
El comentario anterior debe ser la respuesta aceptada. –
El enlace está roto –