Ci sono 4 cose da considerare: separazione di compiti, importanza, dipendenze e dimensioni.
Assiemi, cartelle / pacchetti, classi, funzioni, blocchi - hanno tutti questo in comune.
Una regola generale per le dimensioni di un determinato argomento:
- > 1 class = folder / subfolder.
- > 5-10 classi = sottocartelle.
- > 15-25 classes = assembly.
La mia convinzione è che lo scopo delle classi è più importante della dimensione.
Un esempio di vita reale:
Ho scritto una libreria di analisi della riga di comando molto semplice. Questo finì per essere 3 classi in una cartella "CommandLine" in un assembly di libreria comune ... non era così importante e l'ho usato in due progetti correlati.
Quindi ho dato la fonte di quelle lezioni per aiutare qualcuno con il loro progetto. Qualcun altro l'ha visto e ha suggerito di aggiungere il supporto per gli attributi. Ho colto l'occasione per rifattorizzare il codice, aggiungere test unitari e renderlo una libreria molto più avanzata. Quando lo facevo, l'ho spostato sul proprio assembly in modo da poterlo lavorare autonomamente per diverse notti e per le sue dimensioni, importanza e riutilizzabilità al di fuori della mia libreria comune.
Perché molti assembly sono dolorosi in .net? Direi che l'implementazione e la creazione di nuovi progetti sono marginalmente più difficili con più riferimenti.
Basta aggiungere un progetto esistente alla soluzione e un "riferimento al progetto" per i progetti che dipendono da esso. Fatto.
Potrei vedere un riferimento assemblato compilato come un onere dovuto alla creazione, copia e test in ogni soluzione, ma tu hai l'origine, quindi aggiungi il progetto alla tua soluzione.