Ho usato SignalR per ottenere funzionalità di messaggistica in tempo reale in molti dei miei progetti. Sembra funzionare in modo affidabile ed è molto facile da imparare da usare.
La tentazione, almeno per me, è di abbandonare lo sviluppo di un servizio API Web e utilizzare SignalR per tutto.
Credo che questo potrebbe essere ottenuto con un design accurato, e se lo fosse, significherebbe molto meno codice cliente sarebbe necessario. Ancora più importante, significherebbe che ci sarebbe una singola interfaccia per i servizi piuttosto che un'interfaccia divisa, e nel peggiore dei casi, che si potrebbe collegare a questo senza pensare a quando le cose vengono renderizzate, ecc.
Quindi, vorrei sapere:
- C'è qualche altra ragione per non utilizzare SignalR al posto di tutti i servizi Web oltre alle prestazioni?
- Le prestazioni del SignalR sono sufficientemente rilevanti da non avere senso farlo?
È stato a lungo mio sogno riuscire a tradurre le definizioni di oggetti e servizi lato server sul codice di accesso al servizio lato client senza qualcosa di stupido come node.js . Ad esempio, se definisco un oggetto interessante InterestingObject e un servizio a CRUD l'oggetto InterestingObjectService , posso definire una route URL standard per il servizio, ad esempio "/ {serviceName} / {methodName}", ma Devo ancora scrivere codice client per accedere al servizio. Poiché l'oggetto verrà passato da client a server e viceversa, non c'è alcun motivo pratico per avere per definire l'oggetto esplicitamente nel codice lato client, né dovrebbe esserci la necessità di definire esplicitamente il percorsi per eseguire operazioni CRUD. Mi sembra che ci dovrebbe essere un modo per standardizzare tutto questo in modo che sia possibile scrivere un client partendo dal presupposto che l'accesso al servizio funzioni dal client al server e viceversa in modo trasparente come se scrivessi un WinForm o Java Applet o app nativa o cosa hai.
Se SignalR è abbastanza buono da utilizzare al posto di un servizio web tradizionale, potrebbe essere un modo valido per raggiungere questo obiettivo. SignalR include già funzionalità per far funzionare l'hub come il servizio che descrivo, quindi potrei definire un servizio di base comune (CRUD) che offra tutte queste funzionalità out-of-the-box con una certa riflessione. Quindi potevo quasi dare per scontato l'accesso al servizio, risparmiandomi il fastidio di riscrivere il codice per accedere a qualcosa a cui si poteva accedere per convenzione - e ancora più importante, il tempo che avrei dovuto dedicare alla scrittura del codice per definire come viene aggiornato in il DOM.
Dopo aver letto la mia modifica mi sembra che possa essere un po 'priva di senso, quindi non esitare a chiedermi se hai domande su cosa sto ottenendo. Fondamentalmente, voglio che l'accesso al servizio sia il più trasparente possibile.