Mise en œuvre de mises à jour de données en temps réel dans les applications Mvc avec signaleur

Mécanismes de transport et recul

SignalR prend en charge plusieurs protocoles de transport pour assurer la compatibilité entre différents navigateurs et environnements réseau. Le transport principal est WebSocket, qui offre la plus faible latence et la communication complète. Lorsque WebSocket n'est pas disponible (en raison de restrictions de proxy, de navigateurs plus anciens ou de pare-feu), SignalR revient automatiquement à Server-Sent Events, puis à Forever Frame (pour Internet Explorer), et enfin à Long Polling en dernier recours. Cette négociation automatique fait de SignalR un choix fiable pour les fonctionnalités en temps réel dans divers scénarios de déploiement.

La négociation de transport se déroule lors de la poignée de main initiale de connexion. Le client envoie une requête de négociation, et le serveur répond avec la liste des transports pris en charge. Le client tente alors de se connecter en utilisant le transport le plus capable d'abord. Ce processus est transparent à votre code d'application, mais comprendre il aide lors du débogage des problèmes de connectivité ou l'optimisation pour les environnements WebSocket-seulement.

Cycle de vie de connexion

Chaque connexion client à un hub SignalR est représentée par un ID de connexion unique. Lorsqu'un client se connecte, le serveur peut appeler la méthode du hub pour effectuer toute initialisation. De même, les méthodes et permettent de gérer gracieusement les déconnexions et les reconnections. Les clients SignalR ont une logique de reconnection automatique intégrée, qui peut être configurée pour reessayer à intervalles croissants. Cette résilience est essentielle pour maintenir des expériences en temps réel même lorsque des interruptions réseau se produisent.

Configuration de signalR dans une application ASP.NET MVC

Installer les paquets requis

La première étape consiste à ajouter le paquet SignalR NuGet à votre projet MVC. Vous pouvez le faire via la console Package Manager ou l'interface utilisateur NuGet Package Manager. Pour les applications MVC 5, utilisez . Ce paquet comprend à la fois des composants côté serveur et une bibliothèque JavaScript côté client. Si vous envisagez d'utiliser un cadre JavaScript ou un client non Microsoft, vous pouvez également installer le client JavaScript séparément: .

Après l'installation, vérifiez que les fichiers suivants sont présents dans votre projet :

• – la bibliothèque côté client
• – la version non-minifiée pour le débogage

Enregistrement du signalR dans le démarrage OWIN

ASP.NET MVC 5 utilise OWIN pour les middlewares. SignalR doit être configuré dans la classe de démarrage OWIN. Si votre projet n'a pas déjà de fichier , ajoutez-en un et ajoutez le code suivant:

using Microsoft.Owin;
using Owin;
using YourNamespace; // Replace with your project's namespace

[assembly: OwinStartup(typeof(Startup))]

public class Startup
{
 public void Configuration(IAppBuilder app)
 {
 // Any other OWIN middleware configuration can go here.
 app.MapSignalR();
 }
}

L'appel enregistre le middleware SignalR et map la route par défaut du hub vers . Vous pouvez personnaliser la route en passant un objet , mais pour la plupart des applications, la valeur par défaut est suffisante.

Configuration du Global.asax pour les projets pré-OWIN (Legacy)

Si vous utilisez un projet MVC plus ancien qui ne supporte pas OWIN, vous pouvez configurer SignalR dans la méthode de en appelant . Cependant, cette approche est dépréciée en faveur d'OWIN. Pour un nouveau développement, utilisez toujours la méthode de démarrage OWIN.

Créer un centre et communiquer avec les clients

Classe Hub à l'aide du serveur

Définissez un hub en créant une classe qui hérite de . Dans cette classe, vous pouvez définir des méthodes que les clients peuvent invoquer. Ces méthodes peuvent accepter des paramètres, effectuer une logique côté serveur, puis rappeler aux clients en utilisant la propriété . Voici un exemple simple :

using Microsoft.AspNet.SignalR;
using System.Threading.Tasks;

public class LiveDataHub : Hub
{
 public async Task SendNotification(string userId, string message)
 {
 // Optionally perform server-side validation or storage
 await Clients.User(userId).receiveNotification(message);
 }

 public override Task OnConnected()
 {
 // You can associate the connection with a user/group here
 return base.OnConnected();
 }
}

Dans cet exemple, le hub a une méthode unique qui envoie un message à un utilisateur spécifique. La méthode utilise la cartographie utilisateur intégrée de SignalR, qui nécessite une configuration d'authentification (discutée plus tard). Vous pouvez également utiliser pour diffuser à tous les clients connectés, ou pour envoyer à un groupe spécifique.

Intégration JavaScript à l'aide du client

Du côté client, incluez la bibliothèque JavaScript SignalR et le script mandataire généré automatiquement à . Le script mandataire est généré dynamiquement par le serveur et fournit un accès fortement dactylographié à vos méthodes de hub. Voici une configuration client typique:

<script src="~/Scripts/jquery.signalR-2.4.2.min.js"></script>
<script src="~/signalr/hubs"></script>
<script>
 $(function () {
 // Reference the auto-generated proxy for the hub
 var liveDataHub = $.connection.liveDataHub;

 // Define a client-side method that the hub can call
 liveDataHub.client.receiveNotification = function (message) {
 $('#notifications').append('<p>' + message + '</p>');
 };

 // Start the connection
 $.connection.hub.start().done(function () {
 console.log('Connected to SignalR hub.');
 // Optionally call a server method after connection is established
 // liveDataHub.server.sendNotification('user1', 'Hello from client!');
 }).fail(function (error) {
 console.error('SignalR connection failed: ' + error);
 });
 });
</script>

La méthode initie la connexion avec le meilleur transport disponible. Le callback s'allume après une connexion réussie, et vous pouvez commencer à appeler des méthodes serveur ou à écouter des invocations de méthode client.

Appel des méthodes serveur à partir du client

Pour invoquer une méthode serveur du client, utilisez l'objet . Par exemple, pour appeler la méthode définie ci-dessus :

$('#sendButton').click(function () {
 liveDataHub.server.sendNotification($('#userId').val(), $('#messageInput').val());
});

SignalR sérialise automatiquement les paramètres en utilisant JSON. La méthode serveur fonctionne sur le pool de thread du serveur, et toutes les exceptions sont réalignées au client.

Diffusion des données à partir du code serveur

Des contrôleurs et des tâches de fond

Les hubs SignalR sont généralement invoqués à partir d'actions de contrôleur, de services de background ou d'autres composants côté serveur. Pour envoyer des mises à jour en temps réel à partir d'une méthode hub, vous devez obtenir une référence au contexte hub. Ceci est fait en utilisant :

public class DataController : Controller
{
 public ActionResult Refresh()
 {
 // Simulate a data update
 string newData = GetLatestData();

 // Get the hub context and broadcast to all connected clients
 var hubContext = GlobalHost.ConnectionManager.GetHubContext<LiveDataHub>();
 hubContext.Clients.All.receiveUpdate(newData);

 return Json(new { success = true });
 }
}

Cette approche fonctionne bien pour des scénarios simples. Cependant, pour les tâches de fond à long terme (p. ex., le traitement des files d'attente, le suivi des services externes), envisager d'utiliser un service dédié qui contient une référence au contexte du hub. Vous devez être prudent sur la sécurité des fils et éviter de bloquer le pipeline SignalR.

Utilisation des services de fond avec SignalR

Dans les applications modernes ASP.NET MVC, vous pouvez intégrer SignalR avec BackgroundService[ ou Hosted Services[ (si vous utilisez ASP.NET Core; pour MVC 5, vous pouvez utiliser [] via un hébergement OWIN ou un simple fil de fond). Par exemple, un service qui surveille une base de données pour les modifications peut diffuser des mises à jour lorsque de nouveaux enregistrements apparaissent.

Caractéristiques avancées de SignalR

Utilisation de groupes pour la radiodiffusion sélective

Souvent, vous devez envoyer des mises à jour à un sous-ensemble d'utilisateurs plutôt que tout le monde. SignalR prend en charge groupes qui peuvent être gérés sur le serveur. Les clients peuvent rejoindre ou quitter des groupes en appelant des méthodes dans le hub:

public class ChatHub : Hub
{
 public async Task JoinRoom(string roomName)
 {
 await Groups.Add(Context.ConnectionId, roomName);
 }

 public async Task LeaveRoom(string roomName)
 {
 await Groups.Remove(Context.ConnectionId, roomName);
 }

 public void SendToRoom(string roomName, string message)
 {
 Clients.Group(roomName).receiveMessage(message);
 }
}

Les groupes sont idéaux pour mettre en œuvre des fonctionnalités comme les salles de discussion, les lobbies de jeu en ligne ou les tableaux de bord spécifiques au département. Notez que l'adhésion de groupe est liée à une connexion, pas à un utilisateur.

Messagerie spécifique à l'utilisateur avec authentification

SignalR s'intègre naturellement à ASP.NET Identity. Lorsqu'un utilisateur est authentifié, le contexte du hub expose et l'identité de l'utilisateur est automatiquement associée à la connexion. SignalR fournit un qui map les ID de connexion aux utilisateurs basés sur l'interface . Par défaut, il utilise le nom de l'utilisateur. Vous pouvez alors envoyer des messages à un utilisateur spécifique en utilisant .

Pour envoyer un message à l'utilisateur authentifié actuel à partir d'une méthode hub :

public class PrivateMessagingHub : Hub
{
 public void SendPrivateMessage(string toUser, string message)
 {
 string fromUser = Context.User.Identity.Name;
 Clients.User(toUser).receivePrivateMessage(fromUser, message);
 }
}

L'authentification est essentielle pour de nombreuses fonctionnalités en temps réel, telles que les notifications personnalisées ou les flux de données spécifiques à l'utilisateur. Assurez-vous de configurer l'authentification (cookies, jetons) avant que la connexion SignalR ne soit établie.

Décollage avec un plan arrière

Lorsque votre application fonctionne sur plusieurs serveurs (web farm), vous avez besoin d'un backplane pour synchroniser les messages entre les serveurs. SignalR prend en charge plusieurs fournisseurs de backplane : Redis, SQL Server, Azure Service Bus et des implémentations personnalisées. Le backplane fonctionne en publiant tous les messages de n'importe quel serveur vers le backplane, qui les rediffuse ensuite vers tous les autres serveurs de la ferme.

Pour activer le backplan Redis, installez et configurez-le dans le démarrage OWIN :

app.MapSignalR(new HubConfiguration()
{
 EnableDetailedErrors = false
});

GlobalHost.DependencyResolver.UseRedis(new RedisScaleoutOptions("connectionString", "yourApp"));

Sans backplane, chaque serveur ne connaît que ses propres clients connectés, de sorte que les émissions ne toucheraient pas les clients connectés à d'autres serveurs. Pour les applications de production avec plus d'un serveur, un backplane est obligatoire.

Performance et pratiques exemplaires

Minimiser les appels de méthode Hub

Chaque appel du client au serveur entraîne des frais généraux pour la sérialisation, le transport de latence et le traitement côté serveur. Évitez d'appeler le serveur en boucles serrées. Au lieu de cela, mises à jour par lots sur le client et les envoyer à un intervalle raisonnable.

Utiliser une sérialisation efficace

SignalR utilise JSON pour la sérialisation par défaut. Bien que pratique, JSON peut être verbeux. Si vous avez besoin de performances maximales, envisagez d'utiliser le protocole MessagePack pour SignalR, qui produit des charges utiles plus petites et réduit l'utilisation du processeur.

Gérer les déconnexions avec grâce

Toujours implémenter la logique de reconnection côté client. Le client JavaScript de SignalR a une reconnection intégrée, mais vous pouvez personnaliser les intervalles de réessayer et les tentatives maximales. Du côté du serveur, passer outre pour nettoyer les ressources (par exemple, supprimer l'utilisateur des groupes, annuler les tâches de longue durée associées à cette connexion).

Considérer la taille et la fréquence des messages

L'envoi de messages très importants (par exemple mégaoctets de données) sur SignalR n'est pas recommandé car il bloque le transport et augmente la latence pour d'autres clients. Si vous devez envoyer des fichiers importants, utilisez un mécanisme distinct tel que le téléchargement en morceaux ou les paramètres dédiés.

Cas et exemples d'utilisations dans le monde réel

Tableau de bord et surveillance en direct

SignalR est idéal pour les tableaux de bord en temps réel qui affichent des paramètres changeants tels que les performances de vente, la santé du serveur ou les mentions de médias sociaux. Le serveur peut pousser les valeurs mises à jour toutes les quelques secondes, et le client met simplement à jour l'interface utilisateur. Avec MVC, vous pouvez servir l'état initial du tableau de bord du contrôleur et ensuite utiliser SignalR pour appliquer des mises à jour progressives, fournissant une expérience transparente.

Notifications instantanées

Les notifications pour les nouveaux messages, les demandes d'amis ou les alertes système sont un ajustement naturel pour SignalR. En utilisant des messages spécifiques à l'utilisateur, vous pouvez transmettre des notifications uniquement à l'utilisateur prévu sur tous leurs onglets ou périphériques ouverts.

Édition collaborative et tableau blanc

Les applications qui nécessitent plusieurs utilisateurs pour collaborer sur un document partagé ou une toile bénéficient de la faible latence de SignalR. Chaque modification est diffusée à tous les collaborateurs en temps réel. Pour gérer les conflits, vous pouvez implémenter la transformation opérationnelle ou les types de données repliées sans conflit (CRDT) sur le serveur, mais le transport en temps réel est fourni par SignalR.

Stock Ticker et aliments pour animaux à prix vif

Les applications financières nécessitent souvent des mises à jour de sous-secondes des cours des actions ou des taux de change. SignalR peut gérer des milliers de connexions simultanées et pousser les mises à jour dès qu'elles arrivent d'un flux de données.

Comparaison de signalR avec d'autres technologies en temps réel

Seringue Web brute

L'implémentation directe WebSocket vous donne le plus de contrôle et le plus bas frais généraux, mais vous devez gérer vous-même la sérialisation, la gestion de session, les transports de recul et la logique de reconnection. SignalR absute tout cela, ce qui rend beaucoup plus rapide pour développer des fonctionnalités en temps réel.

Socket.IO (Node.js)

Socket.IO est l'équivalent de SignalR pour les écosystèmes Node.js. Si votre application est construite sur Node.js, Socket.IO offre des solutions de transport automatique similaires et la gestion de la pièce. Cependant, pour une équipe .NET qui utilise ASP.NET MVC, SignalR s'intègre plus naturellement à l'infrastructure et à l'outillage existants.

Base de données en temps réel

Firebase fournit une base de données en temps réel basée sur le cloud avec synchronisation intégrée aux clients. C'est un service entièrement géré, vous évitez donc la gestion du serveur, mais il ajoute le verrouillage du fournisseur et peut être plus coûteux à l'échelle. SignalR vous donne le contrôle complet du côté serveur et peut être hébergé n'importe où, ce qui le rend mieux adapté aux applications qui ont besoin de logiques commerciales personnalisées dans le pipeline de mise à jour.

Conclusion

Mise en œuvre de mises à jour de données en temps réel dans les applications MVC avec SignalR transforme les pages web statiques en expériences dynamiques et engageantes. SignalR gère les complexités de la négociation de transport, de la gestion de connexion et de la messagerie serveur-client, vous permettant de vous concentrer sur les fonctionnalités de construction qui tiennent les utilisateurs informés et connectés.

En suivant les étapes de configuration décrites dans cet article, en créant un hub, en connectant les clients et en tirant parti de fonctionnalités avancées comme les groupes, l'authentification et l'échelle, vous pouvez ajouter des capacités en temps réel à vos applications MVC existantes avec confiance. Au fur et à mesure que vous continuez à développer, consultez la documentation officielle SignalR pour des informations plus approfondies et des dépannages.

Pour plus de détails, consultez les ressources officielles : ASP.NET SignalR Documentation, SignalR Scaleout with Redis et SignalR Hubs API Guide.