Perché non dovrei avere una singola libreria di utilità monolitica?

Question

Abbiamo un paio di librerie comuni (C #, ma credo che questo non sia dalla piattaforma o specifico per la lingua), chiamiamoli A, B, e C. Biblioteca A ha riferimenti a B e C, biblioteca B ha un riferimento a un 3rd-party DLL, e la libreria C sta da solo. L'idea alla base di tre diversi progetti era che ogni biblioteca ha avuto funzionalità distinte, ma Una libreria è diventato nel tempo più o meno "catch-all" libreria comune che la maggior parte ogni cliente riferimenti app. Solo alcune applicazioni di riferimento B e / o C senza A pure.

Stiamo cercando di migliorare le nostre convenzioni controllo del codice sorgente, e una cosa che stiamo cercando di fare è correttamente tag e rilasciare queste DLL di libreria, quindi i file di progetto cliente può puntare a una versione statica del codice anziché il sempre- cambiando tronco. Questo si sta rivelando un po 'contorto -., Ad esempio, un progetto client che fa riferimento sia A e B. A sua volta fa riferimento B, quindi ci sono tecnicamente due riferimenti a B provenienti dal progetto client

Quindi, la cosa più ovvia sembra essere combinare proprio tutto in una singola libreria comune / ripostiglio con spazi dei nomi ben organizzati. Come ho detto, quasi ogni applicazione client fa riferimento a una di queste librerie, quindi chi se ne frega? In questo modo non si introduce alcuna situazioni indesiderabili con dipendenze 3rd-party, e tutte le nostre macchine di destinazione sono interni e mantenere o meno la stessa configurazione dell'ambiente / software.

Questo sembra troppo facile di una soluzione, però, così ho pensato di ottenere almeno un secondo parere. Un'alternativa potrebbe essere quella di usare il GAC e fortemente firmare / versione tutto. Mi sto perdendo qualsiasi cattura qui?

Answer 1

Credo che hai ragione consolidare in una singola libreria.

Molto spesso il codice viene componentizzato in troppe unità dispiegabili che il pezzo logica di funzionalità sembra essere i criteri per la separazione. Questo è sbagliato IMO. I moduli devono essere allineati con gli scenari di distribuzione e cicli di rilascio invece. Altrimenti si finisce con un grafico delle dipendenze terribilmente complesso in cui ogni modo ogni assemblea viene gestita, costruito e distribuito insieme.

Domanda interessante però! Vediamo cosa pensano gli altri:)

Answer 2

Questo è un classico "Riccioli d'oro ei 3 orsi" problema.

Se non si desidera una singola libreria monolitica - e non si vuole troppe librerie. Si vuole esattamente il giusto numero di librerie :) Non troppi, non troppo pochi, appena a destra.

Non ci sono ragioni per avere diverse biblioteche:

1) L'indipendenza dello sviluppo - le librerie possono essere sviluppati in modo indipendente. 2) Più piccolo schierabili

Credo che una regola generale potrebbe essere se c'è una squadra separata che si dedica a fare lo sviluppo a tempo pieno su una particolare sezione della biblioteca, dovrebbe essere separata. Se più squadre aggiungere qualche bit di codice qua e là ogni tanto, quindi non ci dovrebbero essere problemi con l'indipendenza di sviluppo e realizzazione e si potrebbe anche avere una singola libreria comune. Sembra che questo è il caso nella vostra situazione, in modo da andare con una singola libreria.

Un'altra domanda da porsi è "Che problema che stiamo vivendo sarebbe frazionamento biblioteca risolvere?" Se non risolve alcun problema, quindi senza bisogno di librerie separate.

Answer 3

View Point 1
Avendo come poche librerie come possibili semplifica costruire script e distribuzione (minor numero di parti di cui preoccuparsi). Avere una libreria con tutti i componenti dell'interfaccia utente sviluppati internamente è grande per l'avvio di nuovi progetti. Basta aggiungere a quella di riferimento e hai tutti i componenti interni pronti. Speriamo che riduce il tempo speso reinventare i componenti perché qualcuno ha dimenticato c'era già una biblioteca con un tale componente. Stessa cosa con una libreria di utilità generale -. E 'bello avere un solo così hai tutte le funzionalità disponibili con un riferimento

View Point 2
Separando i vari pezzi correlate di funzionalità in librerie separate mantiene queste librerie concentrati e rende loro intento chiaro. Dal momento che ogni biblioteca è più mirato, ogni singola biblioteca sarà più piccolo. Così il vostro pacchetto di distribuzione finale può essere più piccoli in quanto sarete includere solo le librerie che realmente avete bisogno. Tuttavia, è quindi necessario ricordare quante librerie si ha e ciò ognuno contiene. Questo può essere un documentazione e il trasferimento di conoscenze incubo.

Così che cosa è più importante per voi, dimensioni di distribuzione o l'usabilità sviluppatore? Scegli la priorità e quindi abbinare l'organizzazione di codice ad esso.

Answer 4

Sono d'accordo che avere una sola libreria per queste utility è ideale, a patto che gli spazi dei nomi siano adeguatamente mantenuti e il codice stesso è suddiviso bene per qualsiasi futura manutenzione sulla libreria. La principale giustificazione che vedo per questo è esattamente ciò che lei ha citato, quasi tutte le tue applicazioni interne si utilizza.

Tuttavia, una cosa da pensare è la funzionalità di questi pezzi. Se un pezzo è lo spazio dei nomi di utilità per fare trucchi intelligenti con controlli o le etichette, e il secondo pezzo è la libreria di sicurezza che gestisce le procedure di accesso, si può incorrere in alcuni problemi non intenzionali quando "cool trick D" viene aggiunto alla libreria di utilità, ma rompe un'applicazione esistente che fa affidamento sulla libreria di sicurezza, ma è costretto a eseguire l'aggiornamento in quanto l'intera DLL ora è stato aggiornato.

Si potrebbe considerare riscrivere tutte le tre biblioteche in modo da eliminare le dipendenze incrociate e vedere se questo fa per una migliore situazione generale per le tue applicazioni attuali e future.

Answer 5

Ci potrebbe essere un motivo per avere progetti separati per le librerie con completamente diversi scopi, o progetti che fanno riferimento libararies terzi. Diverso da quello che si può mettere più in un libarary base comune.

Abbiamo una libreria comune per un sacco di classi, ma un progetto separato per le classi legate web, un progetto separato per le classi relative PDF (in quanto utilizza una terza DLL di partito che non vogliamo in tutte le applicazioni), un progetto separato per le classi MySQL correlati (in quanto utilizza un connettore di terze parti).

Abbiamo anche un progetto separato per il database (MS SQL) relative classi, ma che potrebbe davvero andati in biblioteca comune come abbiamo così poche applicazioni non usa un database.

Answer 6

Direi che è in realtà solo si riduce a ciò che funziona meglio per voi. Una grande libreria util potrebbe essere difficile trovare le cose in, ma poi di nuovo è tutto in una volta collocare tutti sanno dove andare a cercare essi possono essere di maggior beneficio. Inoltre a seconda di come viene gestita la libreria, può essere più facile per i diversi gruppi di mantenere le proprie librerie util (se hanno bisogno di controllare le modifiche a loro), ma se è gestito da un singolo gruppo (o se tutti vanno d'accordo), poi una grande uno può essere più facile. Quindi, in realtà quello che funziona per voi.

Answer 7

Proprio la condivisione di alcune recenti esperienze che ha causato me avere un leggero cambiamento nel punto di vista su questo ...

La riduzione di 150 progetti in una soluzione a circa 30 ha tagliato il nostro tempo di costruzione di circa il 25% di quello che era (1 minuto e il cambiamento vs 5 minuti sulla nostra macchina tipica dev). Se stai facendo riferimenti dll, non importa più di tanto, ma se si sta compresi i progetti nella soluzione principale, si possono trovare è importante. Per essere onesti, ero un po 'sorpreso che differenza, ma i risultati precedenti non garantisco rendimenti futuri.

Ogni volta .net carica una DLL per la prima volta, si prende il JIT-zione e di file sovraccarico di I / O. Per WinForm / WPF applicazioni in cui l'utente può lanciare più volte al giorno, questo è un problema più grande di applicazioni web. Anche per le applicazioni WinForm / WPF, potrebbe non essere così grande di una preoccupazione per molte applicazioni.

L'altra cosa da guardare fuori per è dipendenze complesse che causano situazioni in cui "se uso A, devo usare B perché A espone i tipi di B. Intanto, io uso raramente B da sé" Basta unire ed essere fare con esso.

Quindi, la mia comprensione è che ci sono un paio di motivi concreti per cercare di consolidare. C'è probabilmente un milione di ragioni soggettive, ma in un grande file di soluzione, sembra meglio cercare di essere un semplice, come si può ragionevolmente tirare fuori.

Più soggettivamente, vorrei anche vi incoraggio a guardare il file di progetto come un artefatto di build e non un codice artefatto. Pensate il file con estensione cs come quello che si davvero desidera riutilizzare e non il .csproj. Certo, la maggior parte delle volte si sarebbe riutilizzare il .csproj come bene e solo costruire il gruppo allo stesso modo per tutto il tempo. Ma, non cercare di sforzarsi di avere dipendenze o un codice di gruppo più di quanto effettivamente necessario nel progetto @. Il rapporto tra Csproj e cs è ragionevolmente sciolto la maggior parte del tempo.

EDIT: @ - aggiunto "in voi progetto"