SignalR
Auparavant, la fonctionnalité de messagerie en temps réel était utilisée dans plusieurs de mes projets. Il semble fonctionner de manière fiable et est très facile à apprendre à utiliser.
La tentation, du moins pour moi, est d'abandonner le développement d'un service API Web et de l'utiliser SignalR
pour tout.
Je pense que cela pourrait être réalisé par une conception réfléchie, et si c'était le cas, cela signifierait beaucoup moins de code client. Plus important encore, cela signifierait qu'il n'y aurait qu'une seule interface vers les services plutôt qu'une interface divisée, et dans le pire des cas, que l'on pourrait la connecter sans penser au moment où les choses seront rendues, etc.
Donc, j'aimerais savoir:
- Existe-t-il une autre raison de ne pas utiliser SignalR à la place de tous les services Web en dehors des performances?
- Est-ce que la performance de SignalR est suffisamment préoccupante pour qu’il n’ait pas de sens de le faire?
Je rêvais depuis longtemps de pouvoir traduire les définitions d’objets et de services côté serveur en code d’accès aux services côté client, sans quelque chose de stupide node.js
. Par exemple, si je définis un objet intéressant InterestingObject
et un service à CRUD
l'objet InterestingObjectService
, je peux définir une route d'URL standard vers le service - par exemple, "/ {serviceName} / {methodName}" - mais je dois néanmoins écrire le code client pour y accéder. le service. Étant donné que l'objet va être passé du client au serveur et inversement, il n'y a aucune raison pratique d' avoirpour définir explicitement l'objet dans le code côté client, il ne devrait pas non plus être nécessaire de définir explicitement les itinéraires pour effectuer des opérations CRUD. Je pense qu’il devrait exister un moyen de normaliser tout cela pour qu’il soit possible d’écrire un client en partant du principe que l’accès au service fonctionne du client au serveur et inversement de manière aussi transparente que si j’écrivais WinForms ou Java. Applet ou application native ou ce que vous avez.
Si SignalR est assez bon à utiliser à la place d'un service Web traditionnel, il peut être un moyen viable d'y parvenir. SignalR inclut déjà des fonctionnalités permettant au concentrateur de fonctionner comme le service que je décris. Je pourrais donc définir un service de base commune (CRUD) qui offrirait toutes ces fonctionnalités prêtes à l'emploi avec un peu de réflexion. Ensuite, je pouvais presque prendre pour acquis l'accès au service, me épargnant le désagrément de réécrire du code pour accéder à quelque chose auquel on pouvait accéder par convention - et plus important encore, le temps qu'il me faudrait pour écrire le code afin de définir comment il est mis à jour les DOM.
Après avoir lu mon montage, je pense que cela peut paraître un peu absurde, alors n'hésitez pas à me demander si vous avez des questions sur ce que je veux en venir. En gros, je veux que l'accès au service soit aussi transparent que possible.