La tua applicazione principale dovrebbe andare in una libreria (statica) - o possibili librerie multiple, una per le entità, una o più altre per casi d'uso, ecc. Dipende dalle dimensioni della tua applicazione. Per semplicità, presumo che le entità e i casi d'uso siano tutti in una libreria di base.
La libreria principale contiene interfacce per comunicare con il resto del mondo.
Ora puoi avere librerie di infrastrutture aggiuntive:
- una libreria per l'interfaccia web
- una libreria per il DB
Entrambe implementano alcune delle interfacce della libreria principale, quindi hanno ovviamente una dipendenza dalla libreria principale (ma non viceversa). Pertanto, è possibile sostituirli in seguito con un'implementazione diversa.
Le classi della libreria di base prevedono l'implementazione delle interfacce. Qui è dove si "inseriscono" le implementazioni effettive dalle proprie librerie di infrastruttura. A tal fine, avrai un progetto separato che lega insieme tutte le tue librerie tramite l'integrazione delle dipendenze e produce l'eseguibile finale che puoi implementare.
In genere, DB e webapp non saranno plug-in letteralmente nel senso che vengono caricati dinamicamente in fase di runtime. Piuttosto, vengono mantenuti separatamente solo fino alla creazione dell'eseguibile finale.
Ovviamente, puoi avere il DB, ecc. come librerie caricate dinamicamente, ma questo ha senso solo se hai qualche motivo per estendere la funzionalità dopo la distribuzione.
Note finali: nulla ti obbliga a mettere le cose in librerie separate, ma lo raccomando. Inoltre, sto ancora aspettando il libro di architettura pulito, ma suppongo che seguirà fondamentalmente questo .
Estendi la mia risposta per indirizzare il tuo commento
Forse posso chiarire con un esempio più specifico:
Se usi un IDE e crei un progetto java, probabilmente ti chiederà se vuoi creare una libreria o un eseguibile. Innanzitutto, crei una libreria, chiamata "core".
In questa libreria implementerai i tuoi controller (ad esempio ReportController , EmployeeManager ), le tue entità (ad esempio Report , Employee , Department , ecc.) e interfacce per cose come l'accesso al database - es %codice%. EmployeeRepository prende un riferimento a EmployeeManager nel suo costruttore che può utilizzare per aggiungere e rimuovere dipendenti. (Vedi iniezione di dipendenza).
Ora potresti creare un nuovo progetto di libreria e chiamarlo "mysqlDB". Puoi fare riferimento alla libreria principale e creare una classe EmployeeRepository che implementa MysqlEmployeeRepository . Separandolo, è possibile sostituirlo in un secondo tempo con un EmployeeRepository senza dover toccare la libreria principale. Questo è il significato del DB come plug-in per l'applicazione.
Tuttavia, in genere (per progetti di dimensioni moderate), non è necessario consentire il collegamento del DB in fase di runtime. Invece, spesso si vuole finire con un singolo eseguibile che è possibile distribuire. Quindi, come passaggio finale, aggiungi un nuovo progetto chiamato "MyPayrollSystem" che fa riferimento alla tua libreria principale, alla tua libreria DB e al resto.
In questo progetto, tutto ciò che fai è
- crea un'istanza del tuo
OracleEmployeeRepository
- crea un'istanza di
MysqlEmployeeRepository e assegna la tua istanza EmployeeManager .
- fai cose simili per configurare tutte le altre parti del tuo sistema, ad es. l'interfaccia web
Il risultato finale è un eseguibile completo e autonomo, ma i singoli componenti vengono solo messi insieme (collegati) nell'ultima parte della compilation.
Ancora una volta, voglio sottolineare che questo non è l'unico modo per farlo. A volte, si potrebbe desiderare di rinviare il caricamento della libreria corretta ancora di più (vale a dire in fase di esecuzione), quindi è possibile caricare la libreria DB in modo dinamico a seconda di un file di configurazione o dei parametri della riga di comando. Ma questo è un passo che dovresti prendere solo se ne hai davvero bisogno.