Quando una classe o un modulo dovrebbe essere in un assembly / DLL separato?

Naviga le tue risposte
18

Ci sono delle linee guida per decidere quando una classe dovrebbe essere nel suo assembly / DLL? Vedo spesso due scuole di pensiero:

1) Ogni "raggruppamento" di classi appartiene alla propria DLL, ad es. Archivi, servizi, DTO, infrastrutture, ecc.

2) Tutto dovrebbe essere in una singola DLL ma separato tramite namespace / cartelle, ad es. avere una DLL "Core" con spazi dei nomi aggiuntivi, ad es. Core.Repositories, Core.Services, Core.DTO, ecc.

Al lavoro ci limitiamo a raggruppare tutto in un unico Assembly chiamato "Business". Ci sono alcune cartelle ma non c'è una vera separazione: gli oggetti business (con la logica, alcuni dei quali non dovrebbero nemmeno essere classi) sono raggruppati in una cartella "BusinessObjects" senza attenzione. Le cose usate in più di una classe sono in una cartella "Core". Le utilità si trovano in una cartella "Utilità", l'infrastruttura di accesso ai dati è una cartella "Dati" - ti viene l'idea.

Per un nuovo modulo su cui sto lavorando Voglio / devo avere un livello di accesso ai dati separato (penso a un'implementazione rudimentale del repository) ma non voglio semplicemente buttarlo nella cartella "BusinessObjects" con gli altri 160 (!) lezioni lì. Allo stesso tempo sono preoccupato di creare una nuova libreria di classi poiché tutti sono abituati a inserire una classe nella singola libreria; tuttavia una cartella / spazio dei nomi potrebbe funzionare.

    
posta Wayne Molina 02.11.2011 - 14:20
fonte

3 risposte

11

Trovo che sia meglio avere più progetti (cioè assiemi) con classi divise per categoria in ciascun progetto rispetto a un progetto con tutte queste classi in spazi dei nomi separati. Dovresti mirare a far sì che i tuoi progetti siano riutilizzabili e rappresentare diversi livelli in un'applicazione. È quindi possibile riutilizzare questi progetti in modo sostenibile in applicazioni future senza dover includere un gruppo di classi inutili.

Ad esempio, in base a ciò che hai menzionato, avrei sicuramente i seguenti progetti:

  • Nucleo
  • Dati
  • Dominio (o BusinessObjects)
  • servizi
  • Utilità (o Helpers)
risposta data 02.11.2011 - 14:33
fonte
12

"Uncle Bob" Martin of Clean Code, SOLID Principles fame ha delineato tre principi qui :

  • Il principio di equivalenza nel riutilizzo del rilascio: il granello di riutilizzo è il granello del rilascio.
  • Il principio di chiusura comune: le classi che cambiano insieme vengono raggruppate insieme.
  • Il principio del riutilizzo comune: le classi utilizzate insieme sono raggruppate insieme.

La regola generale è che dovresti mantenere il numero di progetti nella tua soluzione il più basso possibile. Separateli solo se devi farlo per implementare uno o più user story specifici, o se avere un singolo assembly causa problemi di prestazioni misurabili (in genere una volta che raggiungono dimensioni di diversi megabyte).

    
risposta data 15.07.2014 - 00:56
fonte
4

Alcuni altri principi guida con cui lavoro:

  • Pensi di riutilizzare questo codice in altri progetti? Per un gruppo di applicazioni Web correlate, disponevamo di un modulo relativo all'account utente utilizzato da tutte le applicazioni, poiché tutti utilizzavano lo stesso modello per account utente e accessi. Ho fatto cose simili con le librerie geometriche e matematiche e le ho riutilizzate in più applicazioni, includendo semplicemente la DLL.

  • Vuoi essere in grado di modificare / distribuire questo codice senza ridistribuire / ricompilare l'intero progetto? A volte è stato utile ricostruire il modulo, distribuire e riavviare l'applicazione Web.

Sembra che nel tuo caso un repository di base e generico possa tornare utile in futuro, potrebbe essere utile separarlo in una nuova DLL, se possibile.

    
risposta data 02.11.2011 - 14:33
fonte

Leggi altre domande sui tag

Quando i sistemi diventano sempre più grandi, come fai a mantenere una comprensione globale del tuo sistema? [duplicare] Perché MVC è più popolare del PAC? [chiuso]