Sto cercando di capire qual è la granularità appropriata per le librerie di codici. Nello specifico, voglio capire se tutte le mie librerie di codici generali devono essere inserite in una singola DLL, o se sono meglio separate in DLL separate, una per ogni area discreta di funzionalità.
Sfondo
Ho un set di librerie di codice che sono condivise tra le applicazioni. Includono il codice per gestire l'accesso al database, leggere la configurazione dal nostro repository di configurazione centralizzato, eseguire trasformazioni standard su dati da fonti esterne e un sacco di altre cose. Alcune di queste librerie hanno dipendenze da altre (ad esempio l'accesso al database dipende dal codice del repository di configurazione). Altri sono abbastanza indipendenti. Alcune applicazioni richiedono tutto il codice, ma la maggior parte si limita a utilizzare un sottoinsieme (in cui il sottoinsieme differisce tra le applicazioni).
Se è importante, sono uno sviluppatore C #, che lavora su applicazioni aziendali.
Approccio
Per aiutarmi a capire cosa dovrei fare, ho iniziato a stilare un elenco dei vantaggi e degli svantaggi di ciascun approccio. Purtroppo, questo deve ancora rivelare un chiaro vincitore:
Vantaggi di One Big Library
- Devi solo aggiungere un singolo riferimento alle applicazioni client.
- Devi solo aggiornare una DLL quando è necessario correggere i bug o estendere la funzionalità.
- Ci sono meno file da distribuire, quindi i server di hosting finiscono per sembrare "più puliti". vale a dire. di solito finiscono con un file eseguibile e un file "sharedlibrary.dll".
Vantaggi di più librerie piccole
- Le applicazioni non hanno bisogno di trascinare le dipendenze su funzionalità di cui non hanno bisogno.
- Le dipendenze sono esplicite, quindi è facile vedere cosa dipende da cosa.
- I nomi DLL indicano il tipo di codice che contengono.
La mia domanda
Quali altri fattori dovrei prendere in considerazione? Ho perso vantaggi / svantaggi significativi di entrambi gli approcci?