2010-02-09 9 views
5

Sto creando una libreria da utilizzare con un'applicazione che sto creando. Sto costruendo una struttura dello spazio dei nomi simile a quella in basso.Progetti separati o file di più classi ... best practice per lo spazio dei nomi in C#

MyNamespace.Validation 
MyNamespace.Reports 
MyNamespace.Transactions 
MyNamespace.DataImport 
etc... 

sarebbe buone pratiche per creare una soluzione con più progetti per ogni sotto namespace o un progetto con i file di classe multipli per ogni spazio dei nomi sub? Grazie.

+0

Qualunque scelta: dovresti sempre (o quasi) avere un file per classe. – Svish

risposta

9

Ci sono pro e contro per entrambi gli approcci, che è necessario decidere personalmente tra le proprie circostanze.

Pro a più progetti:

  • gruppi separati permettono al compilatore di fornire una guida più rigoroso, impedendo potenzialmente accoppiamento strisciante attraverso. Questo ti permette di mantenere le dipendenze migliori.
  • Gli assembly separati possono essere caricati come necessario in altri progetti, potenzialmente facilitando il riutilizzo.
  • Gli assembly separati possono impedire il caricamento di codice non necessario in un processo, poiché vengono caricati su richiesta.

Contro a più progetti:

  • Più complesso di distribuzione, come più file devono distribuzione (minore)
  • lento build/compilazione, e anche potenzialmente caricare volte da caricare più gruppi (minore)

Personalmente, penso che i professionisti superano di gran lunga gli svantaggi nella maggior parte dei casi. In genere dividerò i miei spazi dei nomi in assembly separati, a condizione che non siano correlati. Nel tuo caso, stai lavorando su 4 concetti molto diversi, quindi la mia sensazione istintiva è che la divisione abbia più senso.

+0

+1 - anche se mi sposto dall'altra parte, quel primo 'Pro' è un grosso problema. Non vuoi combinare così tante classi da distruggere il significato del modificatore di visibilità 'interno'! –

+0

Sì. Quel primo Pro (e il terzo) è la ragione principale per cui lo faccio tipicamente. –

2

Vorrei andare per l'unica soluzione con più progetti.

Vantaggi:
- Ogni progetto può essere una DLL separata
- Tutti i progetti in un'unica soluzione per una facile navigazione tra i file

1

solito ho seguito il modello con una sola assemblea è uno spazio dei nomi e il nome della DLL è nel namespace. Più facile trovare le DLL per fare riferimento a

3

Direi che dipende.

  • In primo luogo, è consigliabile inserire ogni classe nel proprio file.
  • Se si va con un progetto, vorrei creare cartelle per ogni spazio dei nomi all'interno di quel progetto e inserire i file di codice nella cartella appropriata.
  • fare quanto sopra, Visual Studio crea automaticamente i nuovi file di classe all'interno della corretta namespace

Credo che il vero problema qui è questo, però:

Se questo è sempre e solo sta per essere utilizzato una sola volta, mettere tutto in un unico progetto avrebbe senso. Tuttavia, se questo codice sarà riutilizzabile, dovresti pensare di riutilizzare solo una parte (o un sottospazio) di questa libreria. Se la risposta è sì, suddividerei gli spazi dei nomi in progetti separati, quindi in futuro potresti includere solo i progetti di cui avevi bisogno.

3

Decidere esattamente come suddividere la soluzione è soggettivo, e in realtà dipende dalle specifiche del codice.

Tuttavia, una cosa è certa: il mantenimento di più assiemi presenta degli svantaggi! This article è particolarmente indicato nella descrizione di tali inconvenienti, osservando come aggiungono costi in fase di sviluppo, tempo di compilazione, tempo di implementazione e runtime.

Uso il minor numero possibile di assiemi, mirando a un singolo assieme durante l'isolamento delle aree volatili del dominio. Quando più assiemi sono chiaramente appropriati o richiesti (e spesso lo sono, in particolare per imporre il disaccoppiamento), faccio del mio meglio per raggruppare le interfacce che cambieranno contemporaneamente negli stessi assiemi.