SignalR: Warum Hub vs. Persistent Connection wählen?

Ich habe in letzter Zeit nach SignalR gesucht und nachgelesen, und obwohl ich viele Erklärungen für den Unterschied zwischen Hubs und dauerhaften Verbindungen sehe, konnte ich mich nicht auf das nächste Level konzentrieren, weshalb ich es tun sollte einen Ansatz über den anderen wählen?

Nach dem, was ich im Abschnitt Verbindung und Hubs sehe , scheinen Hubs ein Themensystem bereitzustellen, das die persistenten Verbindungen der unteren Ebene überlagert.

Aus dem hoch bewerteten Kommentar unten:

Teilweise richtig. Sie können Themen oder Gruppen auch in dauerhaften Verbindungen abrufen. Der große Unterschied besteht darin, verschiedene Arten von Nachrichten zu versenden. Zum Beispiel haben Sie verschiedene Arten von Nachrichten und möchten verschiedene Arten von Nutzdaten senden. Bei dauerhaften Verbindungen müssen Sie den Nachrichtentyp in die Nutzdaten einbetten (siehe Raw-Beispiel). Mit Hubs können Sie jedoch RPC über eine Verbindung ausführen (Sie können Methoden auf dem Client vom Server und vom Server zum Client aufrufen). . Eine weitere große Sache ist die Modellbindung. Mit Hubs können Sie stark typisierte Parameter an Methoden übergeben.

In dem in der Dokumentation verwendeten Beispiel wird eine Chatroom-Metapher verwendet, bei der Benutzer einem bestimmten Raum beitreten und dann nur Nachrichten von anderen Benutzern im selben Raum erhalten können. Im Allgemeinen abonniert Ihr Code ein Thema und erhält dann nur Nachrichten, die zu diesem Thema veröffentlicht wurden. Mit den dauerhaften Verbindungen würden Sie alle Nachrichten erhalten.

Sie könnten problemlos ein eigenes Themensystem auf den dauerhaften Verbindungen aufbauen, aber in diesem Fall hat das SignalR-Team die Arbeit bereits für Sie erledigt.

Der Hauptunterschied besteht darin, dass Sie mit PersistentConnection kein RPC ausführen können, sondern nur Rohdaten senden können. Also anstatt Nachrichten vom Server so zu senden

Clients.All.addNewMessageToPage(name, message);

Sie müssten ein Objekt mit Connection.Broadcast()oder senden, Connection.Send()und dann müsste der Client entscheiden, was damit geschehen soll. Sie können beispielsweise ein Objekt wie folgt senden:

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

Und auf dem Client, anstatt einfach zu definieren

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

Sie müssten einen Rückruf hinzufügen, um alle eingehenden Nachrichten zu verarbeiten:

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

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

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

Sie müssten in der OnReceivedMethode die gleiche Art des Versands auf der Serverseite durchführen . Sie müssten dort auch die Datenzeichenfolge deserialisieren, anstatt die stark typisierten Objekte wie bei Hub-Methoden zu empfangen.

Es gibt nicht viele Gründe, PersistentConnection anstelle von Hubs zu wählen. Ein Grund, der mir bekannt ist, ist, dass es möglich ist , vordefinierten JSON über PersistentConnection zu senden , was mit Hubs nicht möglich ist. In bestimmten Situationen kann dies ein relevanter Leistungsvorteil sein.

Beachten Sie außerdem dieses Zitat aus der Dokumentation :

Auswahl eines Kommunikationsmodells

Die meisten Anwendungen sollten die Hubs-API verwenden. Die Connections-API kann unter folgenden Umständen verwendet werden:

• Das Format der tatsächlich gesendeten Nachricht muss angegeben werden.

• Der Entwickler arbeitet lieber mit einem Messaging- und Dispatching-Modell als mit einem Remote-Aufrufmodell.

• Eine vorhandene Anwendung, die ein Messaging-Modell verwendet, wird für die Verwendung von SignalR portiert.

Abhängig von Ihrer Nachrichtenstruktur erhalten Sie möglicherweise auch kleine Leistungsvorteile durch die Verwendung von PersistentConnection.

Vielleicht möchten Sie sich die SignalR-Beispiele ansehen, insbesondere dies hier.

Es gibt zwei Möglichkeiten, SignalR zu verwenden: Sie können auf niedriger Ebene darauf zugreifen, indem Sie die PersistentConnectionKlasse überschreiben , wodurch Sie viel Kontrolle darüber haben. Oder Sie können SignalR das ganze schwere Heben für Sie erledigen lassen, indem Sie die hochrangigen 'Hubs' verwenden.

Persistent Connection ist eine untergeordnete API. Sie können Aktionen zu einem bestimmten Zeitpunkt ausführen, wenn die Verbindung geöffnet oder geschlossen wird. In den meisten Anwendungen ist der Hub die beste Wahl

Beim Vergleich dieser beiden Punkte sind drei Hauptpunkte zu beachten:

• Nachrichtenformat
• Kommunikationsmodell
• SignalR-Anpassung

Bei Hubs wird die Nachrichtenformatierung grundsätzlich von Ihnen übernommen, bei dauerhaften Verbindungen ist die Nachricht jedoch unformatiert und wurde tokenisiert und hin und her analysiert. Wenn die Nachrichtengröße wichtig ist, beachten Sie auch, dass die Nutzlast einer dauerhaften Verbindung viel geringer ist als die eines Hubs.

Wenn es um das Kommunikationsmodell kommt persistente Verbindungen haben im Grunde eine Funktion zum Senden und Empfangen von Messaging während Hub ein nehmen Remote Procedure Call mit einer eindeutigen Funktion pro Anforderung verwenden.

Wenn es um die Anpassung geht, da dauerhafte Verbindungen niedriger sind, können Sie möglicherweise mehr Kontrolle über die Anpassung haben.