SignalR: Por que escolher Hub x Conexão Persistente?

Estive pesquisando e lendo o SignalR recentemente e, enquanto vejo muitas explicações sobre a diferença entre Hubs e Persistent Connections, não consegui entender o próximo nível, e é por isso que escolher uma abordagem sobre a outra?

Pelo que vejo na seção Conexão e Hubs, parece que os Hubs fornecem um sistema de tópicos sobrepondo as conexões persistentes de nível inferior.

Do comentário altamente votado abaixo:

Parcialmente correta. Você também pode obter tópicos ou grupos em conexões persistentes. A grande diferença está no envio de diferentes tipos de mensagens. Por exemplo, você tem diferentes tipos de mensagens e deseja enviar diferentes tipos de cargas úteis. Com conexões persistentes, é necessário incorporar o tipo de mensagem na carga útil (consulte Amostra bruta), mas os hubs permitem executar RPC por uma conexão (permite chamar métodos no cliente a partir do servidor e do servidor para o cliente) . Outra grande coisa é o modelo de ligação. Os hubs permitem passar parâmetros fortemente tipados para métodos.

O exemplo usado na documentação usa uma metáfora da sala de bate-papo, na qual os usuários podem ingressar em uma sala específica e receber apenas mensagens de outros usuários na mesma sala. Mais genericamente, seu código se inscreve em um tópico e recebe apenas mensagens publicadas nesse tópico. Com as conexões persistentes, você recebe todas as mensagens.

Você poderia facilmente criar seu próprio sistema de tópicos sobre as conexões persistentes, mas nesse caso a equipe do SignalR já fez o trabalho para você.

A principal diferença é que você não pode fazer RPC com PersistentConnection, você só pode enviar dados brutos. Então, em vez de enviar mensagens do servidor como este

Clients.All.addNewMessageToPage(name, message);

você teria que enviar um objeto com Connection.Broadcast()ou Connection.Send()e, em seguida, o cliente teria que decidir o que fazer com isso. Você pode, por exemplo, enviar um objeto como este:

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

E no cliente, em vez de simplesmente definir

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

você teria que adicionar um retorno de chamada para lidar com todas as mensagens recebidas:

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

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

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

Você precisaria fazer o mesmo tipo de despacho no lado do servidor no OnReceivedmétodo Você também teria que desserializar a sequência de dados lá, em vez de receber os objetos fortemente tipados, como faz com os métodos do hub.

Não há muitos motivos para escolher PersistentConnection em Hubs. Um motivo pelo qual estou ciente é que é possível enviar JSON pré-serializado via PersistentConnection, o que você não pode fazer usando hubs. Em certas situações, isso pode ser um benefício relevante de desempenho.

Além disso, consulte esta citação na documentação :

Escolhendo um modelo de comunicação

A maioria dos aplicativos deve usar a API de hubs. A API do Connections pode ser usada nas seguintes circunstâncias:

• O formato da mensagem real enviada precisa ser especificado.

• O desenvolvedor prefere trabalhar com um modelo de mensagens e envio em vez de um modelo de chamada remota.

• Um aplicativo existente que usa um modelo de mensagens está sendo portado para usar o SignalR.

Dependendo da estrutura da mensagem, você também pode obter pequenos benefícios de desempenho usando o PersistentConnection.

Você pode dar uma olhada nas amostras do SignalR, especificamente aqui.

Há duas maneiras de usar o SignalR: você pode acessá-lo em um nível baixo, substituindo sua PersistentConnectionclasse, o que oferece muito controle sobre ele; ou você pode deixar o SignalR fazer todo o trabalho pesado para você, usando os 'Hubs' de alto nível.

Conexão Persistente é uma API de nível inferior, você pode executar ações em um horário mais específico quando a conexão é aberta ou fechada. Na maioria dos aplicativos, o Hub é a melhor escolha

Há três pontos principais a serem considerados ao comparar esses dois:

• Formato da Mensagem
• Modelo de comunicação
• Personalização do SignalR

Com os hubs, a formatação da mensagem é basicamente tratada por você, mas com conexões persistentes, a mensagem é bruta e foi tokenizada e analisada para frente e para trás. Se o tamanho da mensagem for importante, observe também que a carga útil de uma conexão persistente é muito menor que a de um hub.

Quando se trata do modelo de comunicação, as conexões persistentes basicamente têm uma função para enviar e receber mensagens, enquanto os hubs adotam um modelo de chamada de procedimento remoto com função exclusiva por requisito.

Quando se trata de personalização, já que as conexões persistentes são de nível mais baixo, elas podem oferecer mais controle sobre a personalização.