Singola istanza del servizio Windows che esegue query su più database

Se il tuo unico obiettivo è ridurre gli sforzi di manutenzione, ti suggerisco invece di apportare al tuo servizio una modifica architettonica così importante, aggiungendo alcuni strumenti che ti consentono di gestire le quattro istanze "come una sola". Ad esempio:

• avviare e arrestare tutte e quattro le istanze contemporaneamente: può essere eseguito avviando e interrompendo gli script

• backup di tutti i dati scritti dai tuoi servizi: lo stesso, alcuni script lo faranno

• producendo un log invece di molti: assicurati che i tuoi servizi utilizzino le meccaniche di logging standard di Windows che collegano tutti gli output di registrazione di diversi processi nel log standard del sistema o dell'applicazione

• utilizzando un solo file di configurazione per tutti e quattro i servizi anziché quattro file: inserisci parametri come la connessione DB (che deve essere diversa per i tuoi quattro casi d'uso) in diverse sezioni per QA, dev, test, produzione all'interno del file di configurazione e separare quelli dai parametri che sono gli stessi per tutte le istanze. In alternativa, continua a utilizzare diversi file di configurazione e fornisci un meccanismo di inclusione per importare i parametri di configurazione uguali per tutte le istanze da un file condiviso.

• e se i tuoi servizi necessitano di più attività di manutenzione, puoi anche raggrupparlo creando uno strumento di gestione speciale, magari uno strumento da riga di comando, magari uno strumento con una GUI, che semplifica la manutenzione.

Immagino che sarà meno impegnativo di unire tutte le istanze in una, e ti lascia ancora in una posizione con tutti i benefici che hai da quattro diverse istanze ora, come l'avvio e l'arresto individuale , fornendo diverse versioni del tuo programma per test e produzione, assicurandoti che un crash dell'istanza di test non influenzi la produzione e così via.

Il servizio Windows è solo un host per la tua applicazione.

Potrei scegliere di scrivere un'applicazione e ospitarla nel processo IIS, nel servizio Windows, nell'applicazione console o nell'applicazione WPF. Il punto che sto facendo è che non importa se si tratta di un servizio di Windows o meno.

Il tuo servizio Windows può ospitare un'applicazione che a sua volta interroga più database. È solo un host che può essere avviato, arrestato, messo in pausa, ripristinato e offre un ripristino di base immediato.

È difficile dire cosa devi fare internamente al tuo servizio per farlo funzionare, ma ciò che stai creando qui è effettivamente un'operazione multi-tenant all'interno del tuo servizio. Si sta aggiungendo un parametro del nome account che deve in qualche modo associare a un'istruzione il database da utilizzare. In realtà è piuttosto semplice se hai una buona iniezione di dipendenza e hai un numero fisso di inquilini.

Ciò non eliminerà del tutto la necessità di una versione di sviluppo completa, a meno che non vogliate entrare in un gioco di gambe molto elaborato, mantenendo in qualche modo più versioni di database e oggetti.

Per quanto riguarda il valore dipende da cosa stai facendo con esso. Ho usato questo tipo di installazione con molto successo in alcuni scenari in cui avevamo consumatori che vorrebbero consumare e testare versioni diverse di dati all'interno della stessa struttura. Ma costruirlo aveva un po 'di overhead quindi non lo farei per le ragioni sbagliate. Tutto sommato, una soluzione migliore potrebbe essere quella di eliminare il dispiegamento piuttosto che costruire la tua app fino alla multi-tenancy. Soprattutto se ci sono differenze di codice tra dev / qa e produzione.