Condivisione della funzionalità dell'interfaccia di database tra più applicazioni

Ci sono diversi modi per risolvere questo problema. Qui proverò a dare alcuni di questi:

1. Avere una versione centralizzata della DLL (ad esempio nell'intranet aziendale) e fare in modo che tutte le app controllino all'avvio (o su un intervallo) se la versione centralizzata differisce da quella attualmente installata per l'applicazione. Se lo è, chiedi di sostituirlo. (Assicurarsi che il file DLL non sia in uso dall'applicazione quando viene sostituito e quindi riavviare l'applicazione. (Assicurarsi che l'utente sappia come salvare il proprio lavoro!)). Come per il commento di @JimmyJames, le informazioni sulla versione devono essere archiviate in un punto in cui l'applicazione può controllarlo facilmente, ad esempio in un database.

2. Utilizzo della potenza di un ambiente di dominio di rete. Supponendo che i computer su cui girano le applicazioni facciano parte dello stesso dominio di rete, potresti avere uno script di avvio (o un altro meccanismo automatizzato) che copia automaticamente la versione più recente della DLL su ciascuno dei computer.

3. Introduci un nuovo modo per connettersi al database. Non sono sicuro di quale funzionalità è stata introdotta nella DLL, ma questa funzionalità potrebbe essere implementata come micro-servizi o servizi web (dai un'occhiata a Architettura orientata ai servizi (SOA) ). In questo modo qualsiasi aggiornamento a queste funzionalità non richiederebbe un aggiornamento di alcuna DLL purché le interfacce non cambiassero. Se lo fanno, dovrebbero essere sostituite solo le applicazioni interessate.

In tutti i casi la tempistica potrebbe essere un problema: se l'aggiornamento della DLL è richiesto a causa di modifiche che non sono retrocompatibili (ad esempio rinominando un nome di colonna o un nome di tabella nel database), dovresti trovare un modo per assicurarti che tutte le applicazioni hanno la nuova DLL dopo che sono state apportate le modifiche al database prima di connettersi al database aggiornato.

Accoppiando direttamente i client al database, gli aggiornamenti saranno sempre un problema.

Con uno strato intermedio, puoi chiamarlo un microservizio o un livello SOA o qualsiasi altra cosa, puoi tenere i due separati.

Il servizio che si trova in mezzo può inoltrare richieste al database per cominciare (o inviare richieste a entrambi e solo restituire la risposta originale) e nessuno saprà che è lì. Quindi puoi cambiare il database e aggiornare il codice che possiedi nel servizio che sta in mezzo e poi decidere come vuoi mapparlo in base a ciò che i clienti si aspettano.

Aggiungendo un sistema di numerazione delle versioni è possibile controllare quali modifiche sono compatibili con le versioni precedenti e inviarle direttamente e quali modifiche richiedono modifiche al client, non solo la DLL di accesso.

Dovrebbe essere il segno che un passaggio a un approccio n-Tier / SOA potrebbe essere vantaggioso per questo progetto.

Forse alcune parti dell'accesso al database possono trarre beneficio non da fare direttamente, da una DLL, ma da un servizio condiviso. Quindi ci sarebbe un singolo punto di modifica / aggiornamento, per l'intero sistema.

In breve: crea il tuo feed del pacchetto NuGet

Dato che stai utilizzando lo stack .NET per lo sviluppo, puoi gestire il tuo pacchetto NuGet feed in cui è possibile posizionare un pacchetto NuGet che contiene l'API del database. È possibile rilasciare diverse versioni al fine di mantenere la retrocompatibilità per l'integrazione dei progetti. Qualsiasi progetto che desideri accedere al database deve solo attivare la console dei pacchetti NuGet in Visual Studio, quindi install-package YourDatabasePackage per includerlo.

Se aggiorni l'API pubblica per il database, rilascerai una versione più recente di quel pacchetto sul server. Chiunque non sia pronto a utilizzare la nuova API rimane nella versione precedente del pacchetto NuGet. Quando arriva il momento di utilizzare la nuova API, attiva nuovamente la console del pacchetto NuGet nel tuo progetto e digita update-package YourDatabasePackage , quindi compila e correggi bug.

Questo fornisce a tutte le applicazioni di integrazione un po 'di tempo di buffer per iniziare a utilizzare la nuova API, ma ti dà anche un modo controllato per distribuire gli aggiornamenti.

Quando aggiungi un nuovo progetto a una soluzione in Visual Studio, puoi guardare i modelli online per un modello di progetto chiamato "NuGet Packager". Questo ti dà un modo in un clic di creare un progetto di pacchetto NuGet che compila il progetto, crea il file DLL e crea il file del pacchetto NuGet quando costruisci la soluzione. È un ottimo modo per iniziare a sviluppare rapidamente i tuoi pacchetti NuGet.

Architettonicamente, descrivi un sistema con un archivio dati e tre attori, con tre casi d'uso. Il sistema dovrebbe fornire i servizi per i casi d'uso. Sembra che tu abbia diversi sistemi che collaborano, non molto bene.

Tenderei a spingere l'API per il database verso il database stesso. Tenderei a scrivere più stored procedure in SQL, ad esempio, e meno codice "esterno" per fornire la maggior parte dell'interfaccia all'archivio dati nell'archivio dati, anziché all'esterno.

Se si trattasse di SQL Server, potrei considerare SQL CLR per comportamenti che non potrebbero essere facilmente implementati nella lingua nativa. L'unico posto in cui è ospitato il comportamento si trova all'interno dell'archivio dati stesso.

Ora potrebbe esserci un sacco di motivi per cui questa non è la strada giusta da percorrere, ma affronta il problema di avere più di una posizione per gli assembly da distribuire.

Ti consiglierei di rivedere il Modello di design del proxy e un concetto di compatibilità con le versioni precedenti fino a quando il Big Bang non cambierà.

Suppongo che tu non stia cambiando le interfacce molto spesso ma solo implementazioni. Questo modello può aiutare a ridurre la necessità di distribuzione della DLL per ogni piccolo cambiamento. In questo modo, i proxy indicheranno l'implementazione reale e cambierai solo il soggetto reale in un unico posto, probabilmente molto vicino al DB.

Potresti implementare il modello proxy per le tue DLL come DCOM (vecchio ma funziona ancora). Oppure puoi racchiudere le chiamate dll tramite un servizio (web) (SOA) che consuma la tua DLL.