In .NET (Visual Studio), quando si crea un nuovo assembly?

Sto lavorando a un'applicazione Silverlight. L'ho diviso in diversi assiemi:

Dominio
Repository (tutto con persistente nel database Sterling)
UI
...

È così che l'ho imparato, ma mi chiedevo. Se sai che le DLL non verranno riutilizzate, è necessario dividerle? O potresti mettere tutto in un assieme e usare cartelle e spazi dei nomi per tenerlo in ordine?

Ho anche visto progetti che hanno troppi assemblaggi. Invece di usare spazi dei nomi dove sarebbe stato appropriato.

Quindi: quando crei un nuovo assembly per qualche nuovo pezzo di codice? Qualche buona risorsa su questo argomento? E dividi il codice tecnicamente (dominio, dati, interfaccia utente, ecc.) E / o funzionalmente (ad es. Amministrazione paziente, paziente medico, logistica ospedaliera, ... - probabilmente solo per applicazioni più grandi, di livello aziendale)?

— Peter
fonte

Risposte:

Consiglio di creare assiemi separati per le classi che rientrano logicamente in "moduli". Non solo è utile per il riutilizzo e la manutenzione, ma è anche un modo per imporre il minor numero di dipendenze tra le classi.

La missione sarà quella di ridurre al minimo il numero di riferimenti ad altre assemblee di cui ogni assemblea ha bisogno, principalmente questo sarà fatto attraverso interfacce ed eventi. Avere classi in diversi assiemi renderà le dipendenze molto ovvie. Al contrario, se si utilizza un solo assieme, è molto facile trascurare il pensiero delle dipendenze poiché tutto è accessibile.

Ovviamente non dovresti esagerare ma separare dove appropriato. Pensaci in questo modo: "Queste classi si uniscono e non hanno bisogno di conoscere queste classi" e separano lungo quelle linee

— Homde
fonte

Dipende da cosa intendi per "moduli", ma in genere divido la logica correlata utilizzando gli spazi dei nomi anziché gli assembly. Ricorda, gli spazi dei nomi possono estendersi agli assembly. Gli assiemi sono l'unità di distribuzione e pertanto è consigliabile tagliare gli assiemi per adattarli allo scenario di distribuzione.

— Ed James,

Non è una buona idea. VS diventa molto lento quando una soluzione contiene più di alcuni progetti.

— nikie,

Se il tuo VS diventa troppo lento, stai eseguendo una versione precedente o un computer lento. Ho progetti enormi con oltre 30 progetti che vengono compilati in pochi secondi. Poi di nuovo ho un sacco di ram, core e un SSD :) Non dovresti esagerare ovviamente, ma solo separare dove appropriato, pensaci in questo modo "Queste classi si uniscono e non hanno bisogno di conoscerle" e separati secondo queste linee

— Homde,

Contrassegnato come risposta a causa dell'osservazione sulle dipendenze. La risposta di Ed James è almeno altrettanto preziosa e corretta, ma questa risposta è più applicabile alla mia situazione.

— Peter,

Seguendo questo approccio si potrebbe finire con un mucchio di assemblee: A, B, C, D, E, F, G, H, I, J, K. Ovunque si fa riferimento assembly A, è necessario inoltre fare riferimento suoi assembly dipendenti: B, C, D. Ma il montaggio Cdipende da: E, F, G, Hquindi stiamo andando ad avere bisogno anche quelle. Quindi ogni volta che hai bisogno di qualche funzione Adevi abbattere 7 assiemi aggiuntivi per farlo funzionare; assicurandoti di ottenere le versioni corrette di ciascun assieme. Benvenuti nella nuova DLL Hell.

— Ed James,

Un assembly è l'unità di distribuzione per un'applicazione .NET; pertanto, è consigliabile prendere in considerazione l'abbinamento del taglio degli assiemi con l'architettura di distribuzione.

Gli assembly sono utili anche quando è necessario un controllo versione separato su un codice. Ad esempio, quando si hanno interfacce comuni che trarrebbero vantaggio dal controllo indipendente della versione, è necessario separare quel codice in un assembly.

Ricorda che gli spazi dei nomi possono estendersi agli assembly. In molti casi è sufficiente separare il comportamento usando gli spazi dei nomi. Guarda .NET mscorlib.dllche in un singolo assembly contiene codice che copre una vasta gamma di comportamenti separati solo dallo spazio dei nomi.

Se vuoi un po 'di autorità su questo argomento, non cercare oltre:

Linee guida per la progettazione del framework

Linee guida per la progettazione di strutture: convenzioni, modi di dire e schemi per librerie .NET riutilizzabili (2a edizione) di Krzysztof Cwalina e Brad Abrams.

— Ed James
fonte

Grazie davvero per il riferimento al libro. Lo controllerò. Potresti approfondire l'architettura di implementazione? In che modo la distribuzione di 10 file DLL differisce dalla distribuzione di 1? A meno che tu non sia in grado di aggiornare uno dei dieci file, mentre gli altri rimangono intatti?

— Peter,

@Peter: se hai codificato 10 assembly che sono sempre distribuiti insieme, potresti avere un controllo e una distribuzione della versione semplificati inserendo tutto il codice in un singolo assembly. Se i 10 assiemi non vengono sempre distribuiti insieme, possono essere utili disporre di assiemi separati.

— Ed James,