SignalR: почему стоит выбрать Hub vs. Persistent Connection?

Я недавно искал и читал в SignalR, и, хотя я вижу много объяснений того, в чем разница между концентраторами и постоянными соединениями, я не смог разобраться со следующим уровнем, поэтому мне бы хотелось выбрать один подход по сравнению с другим?

Из того, что я вижу в разделе « Соединения и концентраторы», кажется, что концентраторы предоставляют систему тем, перекрывающую постоянные соединения нижнего уровня.

Из высоко голосованного комментария ниже:

Частично правильно. Вы также можете получить темы или группы в постоянных соединениях. Большая разница в рассылке разных типов сообщений. Например, у вас есть разные виды сообщений, и вы хотите отправлять разные виды полезных данных. При постоянных соединениях вы должны встраивать тип сообщения в полезную нагрузку (см. Пример Raw), но концентраторы дают вам возможность выполнять RPC через соединение (позволяет вызывать методы на клиенте с сервера и с сервера на клиент) , Еще одна важная вещь - привязка модели. Концентраторы позволяют передавать строго типизированные параметры в методы.

В примере, используемом в документации, используется метафора чата, в которой пользователи могут присоединиться к определенной комнате, а затем получать сообщения только от других пользователей в той же комнате. В общем, ваш код подписывается на тему, а затем публикует только сообщения на эту тему. При постоянных соединениях вы получите все сообщения.

Вы можете легко построить свою собственную систему тем поверх постоянных соединений, но в этом случае команда SignalR уже поработала за вас.

Основное отличие состоит в том, что вы не можете выполнять RPC с PersistentConnection, вы можете только отправлять необработанные данные. Так что вместо отправки сообщений с сервера вот так

Clients.All.addNewMessageToPage(name, message);

вам нужно будет отправить объект с помощью Connection.Broadcast()или, Connection.Send()а затем клиенту придется решить, что с этим делать. Вы можете, например, отправить объект следующим образом:

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

И на клиенте, а не просто определяя

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

вам нужно добавить обратный вызов для обработки всех входящих сообщений:

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

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

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

В этом OnReceivedметоде вам придется выполнить такую ​​же диспетчеризацию на стороне сервера . Вам также придется десериализовать строку данных там вместо того, чтобы получать строго типизированные объекты, как вы делаете это с помощью методов-концентраторов.

Не так много причин выбирать PersistentConnection вместо Hubs. Одна из причин, по которой я знаю, заключается в том, что можно послать пре-сериализованный JSON через PersistentConnection, чего нельзя сделать с помощью концентраторов. В определенных ситуациях это может быть значительным улучшением производительности.

Кроме того, смотрите эту цитату из документации :

Выбор модели общения

Большинство приложений должны использовать Hubs API. API-интерфейс Connections можно использовать в следующих случаях:

• Формат фактического отправленного сообщения должен быть указан.

• Разработчик предпочитает работать с моделью обмена сообщениями и рассылки, а не с моделью удаленного вызова.

• Существующее приложение, использующее модель обмена сообщениями, переносится для использования SignalR.

В зависимости от структуры вашего сообщения, вы также можете получить небольшие преимущества от использования PersistentConnection.

Возможно, вы захотите взглянуть на образцы SignalR, особенно здесь.

Есть два способа использования SignalR: вы можете получить к нему доступ на низком уровне, переопределив его PersistentConnectionкласс, что дает вам большой контроль над ним; или вы можете позволить SignalR выполнить всю тяжелую работу за вас, используя «Hubs» высокого уровня.

Постоянное соединение - это API более низкого уровня, вы можете выполнять действия в более определенное время, когда соединение открыто или закрыто, в большинстве приложений концентратор является лучшим выбором

При сравнении этих двух факторов необходимо учитывать три основных момента:

• Формат сообщения
• Модель связи
• Настройка SignalR

С концентраторами форматирование сообщений в основном обрабатывается вами, но при постоянных соединениях сообщение является необработанным, и его токенизируют и анализируют взад и вперед. Если размер сообщения важен, также обратите внимание, что полезная нагрузка для постоянного соединения намного меньше, чем для концентратора.

Когда речь идет о модели связи, постоянные соединения в основном имеют функцию для отправки и получения сообщений, в то время как концентраторы используют модель удаленного вызова процедур с уникальной функцией в соответствии с требованием.

Когда дело доходит до настройки, поскольку постоянные соединения находятся на более низком уровне, они могут дать вам больший контроль над настройкой.