SignalR: Pourquoi choisir Hub vs Connexion persistante?

J'ai récemment cherché et lu sur SignalR et, bien que je vois beaucoup d'explications sur la différence entre les hubs et les connexions persistantes, je n'ai pas été en mesure de passer au niveau suivant, c'est pourquoi je choisir une approche plutôt qu'une autre?

D'après ce que je vois dans la section Connexion et concentrateurs, il semble que les concentrateurs fournissent un système de rubriques superposant les connexions persistantes de niveau inférieur.

D'après le commentaire hautement voté ci-dessous:

Partiellement correct. Vous pouvez également obtenir des sujets ou des groupes dans des connexions persistantes. La grande différence est l'envoi de différents types de messages. Par exemple, vous avez différents types de messages et vous souhaitez envoyer différents types de charges utiles. Avec les connexions persistantes, vous devez incorporer le type de message dans la charge utile (voir exemple brut), mais les concentrateurs vous permettent de faire du RPC via une connexion (vous permet d'appeler des méthodes sur le client du serveur et du serveur au client) . Un autre élément important est la liaison de modèles. Les hubs vous permettent de transmettre des paramètres fortement typés aux méthodes.

L'exemple utilisé dans la documentation utilise une métaphore de salle de discussion, dans laquelle les utilisateurs peuvent rejoindre une salle spécifique et ne recevoir que les messages des autres utilisateurs de la même salle. De manière plus générique, votre code s'abonne à un sujet, puis ne reçoit que les messages publiés sur ce sujet. Avec les connexions persistantes, vous recevrez tous les messages.

Vous pouvez facilement créer votre propre système de sujets en plus des connexions persistantes, mais dans ce cas, l'équipe SignalR a déjà fait le travail pour vous.

La principale différence est que vous ne pouvez pas faire de RPC avec PersistentConnection, vous ne pouvez envoyer que des données brutes. Donc, au lieu d'envoyer des messages du serveur comme celui-ci

Clients.All.addNewMessageToPage(name, message);

il faudrait envoyer un objet avec Connection.Broadcast()ou Connection.Send(), puis le client devrait décider quoi faire avec ça. Vous pouvez, par exemple, envoyer un objet comme celui-ci:

Connection.Broadcast(new {
    method: "addNewMessageToPage",
    name: "Albert",
    message: "Hello"
});

Et sur le client, au lieu de simplement définir

yourHub.client.addNewMessageToPage = function(name, message) { 
    // things and stuff
};

vous devrez ajouter un rappel pour gérer tous les messages entrants:

function addNewMessageToPage(name, message) {
    // things and stuff
}

connection.received(function (data) {
    var method = data.method;

    window[method](data.name, data.message);
});

Vous devrez faire le même type de répartition côté serveur dans la OnReceivedméthode. Vous devrez également désérialiser la chaîne de données au lieu de recevoir les objets fortement typés comme vous le faites avec les méthodes hub.

Il n'y a pas beaucoup de raisons de choisir PersistentConnection sur Hubs. Une raison dont je suis consciente est qu'il est possible d' envoyer du JSON présérialisé via PersistentConnection, ce que vous ne pouvez pas faire à l'aide de hubs. Dans certaines situations, cela peut être un avantage de performance pertinent.

En dehors de cela, consultez cette citation de la documentation :

Choisir un modèle de communication

La plupart des applications doivent utiliser l'API Hubs. L'API Connections peut être utilisée dans les circonstances suivantes:

• Le format du message réel envoyé doit être spécifié.

• Le développeur préfère travailler avec un modèle de messagerie et de répartition plutôt qu'un modèle d'appel à distance.

• Une application existante qui utilise un modèle de messagerie est en cours de portage pour utiliser SignalR.

En fonction de la structure de votre message, vous pouvez également bénéficier de petits avantages en termes de performances en utilisant PersistentConnection.

Vous voudrez peut-être jeter un coup d'œil aux exemples SignalR, en particulier ici.

Il existe deux façons d'utiliser SignalR: vous pouvez y accéder à un niveau bas en remplaçant sa PersistentConnectionclasse, ce qui vous donne beaucoup de contrôle sur celui-ci; ou vous pouvez laisser SignalR faire tout le gros du travail pour vous, en utilisant les «Hubs» de haut niveau.

La connexion persistante est une API de niveau inférieur, vous pouvez effectuer des actions à un moment plus spécifique lorsque la connexion est ouverte ou fermée, dans la plupart des applications, le hub est le meilleur choix

Il y a trois points principaux à considérer lors de la comparaison de ces deux:

• Format du message
• Modèle de communication
• Personnalisation de SignalR

Avec les hubs, le formatage des messages est essentiellement géré par vous, mais avec des connexions persistantes, le message est brut et a été tokenisé et analysé dans les deux sens. Si la taille du message est importante, notez également que la charge utile d'une connexion persistante est bien inférieure à celle d'un hub.

En ce qui concerne le modèle de communication, les connexions persistantes ont essentiellement une fonction d'envoi et de réception de messages, tandis que les concentrateurs utilisent un modèle d' appel de procédure à distance avec une fonction unique par exigence.

En ce qui concerne la personnalisation, les connexions persistantes étant de plus bas niveau, elles peuvent vous donner plus de contrôle sur la personnalisation.