Riutilizzo basato su server: DLL, GAC o REST?

Question

Abbiamo una funzionalità che viene utilizzata da diverse applicazioni (client) sullo stesso server. Può essere modellato come un servizio, ha un database back-end e ci sarà solo una versione della funzionalità e del database in uso alla volta.

Fino ad ora abbiamo utilizzato un semplice riutilizzo della DLL, con la funzionalità, il suo file di configurazione e le dipendenze distribuite ovunque venga utilizzato. Poiché ora è necessario apportare diverse modifiche in diversi punti, questo metodo è doloroso quando si creano nuove versioni della funzionalità o quando i nuovi clienti vogliono usarla.

Ci chiediamo se esiste un modo migliore per farlo e abbiamo escogitato due possibili alternative.

1. Inserisci la DLL (e le dipendenze) nel GAC. La domanda è quindi come configurare il componente. Poiché i client non hanno interesse per la configurazione, ci stiamo adoperando per archiviare il file di configurazione in un percorso hardcoded sul server.

2. Pubblica la funzionalità come servizio interno (basato su REST). L'accesso ad esso può essere limitato ai client interni che utilizzano il firewall.

A nostro avviso, i vantaggi del n. 1 sembrano essere prestazioni e possibilmente sicurezza, mentre il n. 2 può essere visto come più semplice da configurare.

Qui ci manca qualcosa di importante? Qualcuno si è mai trovato in una situazione simile prima e vuole condividere alcune intuizioni?

Answer 1

Questo è un problema con cui ho lottato molte volte e non c'è davvero nessuna risposta migliore, quindi dipende. La mia opinione personale è che devi stare lontano dall'opzione 1 per un paio di motivi:

1. Avendo tutti i tuoi clienti che condividono un singolo binario, ora sarà necessario testare tutti i tuoi client ogni volta che lo modifichi. Ora so che nel tuo caso esatto potresti doverlo fare comunque poiché possiamo supporre che tu stia modificando il database che si trova dietro il componente.
2. Non codificare nulla. È possibile memorizzare il percorso di configurazione in una sezione AppSettings nel file machine.config.

Per quanto riguarda l'opzione 2, un'alternativa sarebbe usare WCF (supponendo che l'ambiente possa supportarlo). Utilizzando WCF è quindi possibile utilizzare un trasporto TCP utilizzando la serilizzazione binaria (e potrebbe esserci un trasporto di memoria condivisa). Entrambi aiuterebbero ad avvicinare il gap prestazionale (sebbene l'opzione 1 sovraperformerà sempre un approccio basato sul servizio).

Andando con l'opzione 2 si allevia anche la necessità di ripetere il test di tutti i clienti, in quanto è possibile sviluppare test automatizzati per convalidare che il contratto non è rotto. Ciò ti consentirà di pubblicare in un unico luogo, eseguire test automatici rapidi e sapere che non stai rompendo i client.

Detto questo, puoi fare la stessa cosa usando l'opzione 1 e una buona serie di test unitari, ma sulla base della mia esperienza l'opzione 2 sarà più facile a lungo termine.

L'opzione 2 ti consente anche di ridimensionare il servizio in futuro se hai bisogno di più potenza della CPU.

Personalmente penso che l'opzione 1 sia più facile da configurare, poiché non dovrai occuparti di configurare il firewall, gestire l'autenticazione, impostare un servizio ecc ... Sarà anche più facile eseguire il debug (la distribuzione di un'applicazione introduce nuove tipi di errori, ad esempio il sito che ospita il servizio si arresta in modo anomalo e i client iniziano a ricevere errori).

Un ultimo suggerimento è di utilizzare un modello di proxy / facciata per isolare i clienti dalla posizione effettiva del servizio. Ciò ti consentirà di espandersi nel tempo senza dover modificare il codice client.

Answer 2

Come già detto da Josh, purtroppo la risposta a questo tipo di domande è spesso "dipende".

Sono un grande fan di GAC, ma dovresti solo inserire il codice di cui sei sicuro che funzioni (quasi) perfettamente e non deve essere aggiornato molto spesso. Finché un pezzo di codice è "in fase di sviluppo", basta pubblicarlo insieme a tutte le applicazioni che lo utilizzano.

Answer 3

Direi che l'utilizzo dell'opzione 1 sarebbe più semplice e più facile, soprattutto perché dovrai solo dedicare più tempo a limitare la disponibilità del REST. (gioco di parole!)

Answer 4

Josh indica WCF come opzione, e questo è sicuramente il modo in cui andrei con questo.

Questo problema è esattamente ciò che SOA dovrebbe risolvere!