Le cartelle in una soluzione devono corrispondere allo spazio dei nomi?


129

Le cartelle in una soluzione devono corrispondere allo spazio dei nomi?

In uno dei progetti dei miei team, abbiamo una libreria di classi che ha molte sottocartelle nel progetto.

Nome del progetto e Namespace: MyCompany.Project.Section.

All'interno di questo progetto, ci sono diverse cartelle che corrispondono alla sezione dello spazio dei nomi:

  • La cartella Vehiclesha classi nello MyCompany.Project.Section.Vehiclesspazio dei nomi
  • La cartella Clothingha classi nello MyCompany.Project.Section.Clothingspazio dei nomi
  • eccetera.

All'interno di questo stesso progetto, c'è un'altra cartella canaglia

  • La cartella BusinessObjectsha classi nello MyCompany.Project.Sectionspazio dei nomi

Ci sono alcuni casi come questo in cui le cartelle sono create per "comodità organizzativa".

La mia domanda è: qual è lo standard? Nelle librerie di classi le cartelle di solito corrispondono alla struttura dello spazio dei nomi o è un miscuglio?


9
Nota: ReSharper si lamenterà se gli spazi dei nomi non corrispondono alla gerarchia delle cartelle.
Fred

Risposte:


77

Inoltre, si noti che se si utilizzano i modelli integrati per aggiungere classi a una cartella, per impostazione predefinita verrà inserito in uno spazio dei nomi che riflette la gerarchia delle cartelle.

Le lezioni saranno più facili da trovare e questo da solo dovrebbe essere ragioni abbastanza buone.

Le regole che seguiamo sono:

  • Il nome del progetto / assembly è uguale allo spazio dei nomi radice, ad eccezione del finale .dll
  • L'unica eccezione alla regola di cui sopra è un progetto con una fine .Core, il .Core viene rimosso
  • Le cartelle equivalgono a spazi dei nomi
  • Un tipo per file (class, struct, enum, delegate, ecc.) Semplifica la ricerca del file giusto

1
+1 per "L'unica eccezione alla regola sopra è un progetto con una fine .Core, il .Core è rimosso" da solo. Ho MyProject.Core.dllun'assemblea e tutte le classi iniziano con MyProject.Core. Eliminare il .Coresuffisso ha molto più senso.
Luiz Damim,

2
Un'altra eccezione che potrei aggiungere è alle eccezioni. Le eccezioni sono già contrassegnate con "Eccezione", pertanto uno spazio dei nomi aggiuntivo è ridondante. Può anche diventare disordinato avere una parte dello spazio dei nomi con la parola Eccezione (può portare a confondere System.Exception). Tuttavia, organizzarli in cartelle è abbastanza utile.
phillipwei,

55

No.

Ho provato entrambi i metodi su progetti piccoli e grandi, sia con single (me) che con un team di sviluppatori.

Ho scoperto che la via più semplice e produttiva era quella di avere un singolo spazio dei nomi per progetto e tutte le classi andavano in quello spazio dei nomi. Sei quindi libero di inserire i file di classe in qualunque cartella di progetto desideri. Non si scherza sull'aggiunta delle istruzioni using nella parte superiore dei file in quanto esiste un solo spazio dei nomi.

È importante organizzare i file di origine in cartelle e, a mio avviso, è necessario utilizzare tutte le cartelle. Richiedere che queste cartelle si associno anche agli spazi dei nomi non è necessario, crea più lavoro e ho scoperto che era effettivamente dannoso per l'organizzazione perché l'onere aggiunto incoraggia la disorganizzazione.

Prendi questo avviso FxCop per esempio:

CA1020: Evitare gli spazi dei nomi con pochi tipi
causa: Uno spazio dei nomi diverso dallo spazio dei nomi globale contiene meno di cinque tipi https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Questo avviso incoraggia il dumping di nuovi file in una cartella Project.General generica o persino nella radice del progetto fino a quando non si hanno quattro classi simili per giustificare la creazione di una nuova cartella. Succederà mai?

Trovare file

La risposta accettata dice "Le lezioni saranno più facili da trovare e che da sole dovrebbero essere ragioni abbastanza buone".

Sospetto che la risposta si riferisca al fatto di avere più spazi dei nomi in un progetto che non si associano alla struttura delle cartelle, piuttosto che quello che sto suggerendo che è un progetto con un singolo spazio dei nomi.

In ogni caso, mentre non è possibile determinare in quale cartella si trova un file di classe dallo spazio dei nomi, è possibile trovarlo utilizzando Vai a definizione o la casella di esplorazione della soluzione di ricerca in Visual Studio. Anche questo non è davvero un grosso problema secondo me. Non dedico nemmeno lo 0,1% del mio tempo di sviluppo al problema di trovare i file per giustificare l'ottimizzazione.

Scontri di nome

Sicuramente la creazione di più spazi dei nomi consente al progetto di avere due classi con lo stesso nome. Ma è davvero una buona cosa? È forse più facile impedire che ciò sia possibile? Consentire due classi con lo stesso nome crea una situazione più complessa in cui il 90% delle volte le cose funzionano in un certo modo e poi all'improvviso scopri di avere un caso speciale. Supponi di avere due classi Rectangle definite in spazi dei nomi separati:

  • classe Project1.Image.Rectangle
  • classe Project1.Window.Rectangle

È possibile risolvere un problema che richiede che un file di origine includa entrambi gli spazi dei nomi. Ora devi scrivere lo spazio dei nomi completo ovunque in quel file:

var rectangle = new Project1.Window.Rectangle();

O pasticciare con qualche brutta dichiarazione usando:

using Rectangle = Project1.Window.Rectangle;

Con un singolo spazio dei nomi nel tuo progetto sei costretto a inventare nomi diversi, e direi più descrittivi, come questo:

  • classe Project1.ImageRectangle
  • classe Project1.WindowRectangle

E l'utilizzo è lo stesso ovunque, non è necessario affrontare un caso speciale quando un file utilizza entrambi i tipi.

usando le dichiarazioni

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

vs

using Project1;

La facilità di non dover aggiungere sempre spazi dei nomi durante la scrittura del codice. Non è il tempo che ci vuole davvero, è l'interruzione del flusso di doverlo fare e riempire semplicemente i file con molte dichiarazioni usando - per cosa? Ne vale la pena?

Modifica della struttura delle cartelle del progetto

Se le cartelle sono mappate su spazi dei nomi, il percorso della cartella del progetto viene effettivamente codificato in modo rigido in ciascun file di origine. Ciò significa che qualsiasi rinomina o spostamento di un file o di una cartella nel progetto richiede che il contenuto del file effettivo cambi. Sia la dichiarazione dello spazio dei nomi dei file in quella cartella sia l'utilizzo di istruzioni in un intero gruppo di altri file che fanno riferimento alle classi in quella cartella. Mentre le modifiche stesse sono banali con gli strumenti, di solito si traduce in un grande commit costituito da molti file le cui classi non sono nemmeno cambiate.

Con un singolo spazio dei nomi nel progetto è possibile modificare la struttura delle cartelle del progetto come desiderato senza che vengano modificati i file di origine.

Visual Studio mappa automaticamente lo spazio dei nomi di un nuovo file sulla cartella del progetto in cui è stato creato

Sfortunato, ma trovo che la seccatura di correggere lo spazio dei nomi sia meno della seccatura di affrontarli. Inoltre ho l'abitudine di copiare e incollare un file esistente piuttosto che usare Aggiungi-> Nuovo.

Intellisense e Object Browser

Il più grande vantaggio secondo me dell'utilizzo di più spazi dei nomi in progetti di grandi dimensioni è avere un'organizzazione extra quando si visualizzano le classi in qualsiasi strumento che mostra le classi in una gerarchia degli spazi dei nomi. Anche documentazione. Ovviamente avere un solo spazio dei nomi nel progetto fa sì che tutte le classi vengano visualizzate in un unico elenco anziché suddivise in categorie. Tuttavia personalmente non sono mai stato sconcertato o ritardato a causa della mancanza di questo, quindi non trovo un vantaggio abbastanza grande da giustificare più spazi dei nomi.

Anche se se stessi scrivendo una grande libreria di classi pubbliche , probabilmente userei più spazi dei nomi nel progetto in modo che l'assemblaggio sembrasse pulito negli strumenti e nella documentazione.


30
Questa è onestamente una delle soluzioni più da incubo che ho sentito suggerire. Se lavori su piccoli progetti per il mondo, allora questo consiglio funziona, ma immagina di avere oltre 1000 file .cs. Provocherebbe così tanti problemi che non so da dove cominciare.
BentOnCoding

10
"ma immagina di avere oltre 1000 file .cs". Ho lavorato in progetti di quelle dimensioni con un singolo spazio dei nomi. Va bene. Quale disastro pensi che accadrebbe?
Weyland Yutani

14
+1 per pensare. Non credo di essere pronto a ridurre i miei spazi dei nomi a uno per progetto, ma dopo aver lavorato su un framework di grandi dimensioni sto esplorando la riduzione del numero di spazi dei nomi per ridurre il numero di istruzioni usando e per aiutare la rilevabilità dei metodi di estensione. Penso che questa risposta offra un buon spunto di riflessione. Grazie.
Lee Gunn,

3
@WeylandYutani So di essere in ritardo ma devo dire che questa frase: you can find it by using Go To Definition or the search solution explorer box in Visual Studionon è sempre vera. Provalo per un sacco di eredità e interfacce ... buona fortuna per trovare il file giusto.
Emmanuel M.,

11
Questo è uno dei migliori consigli che abbia mai visto. Gli spazi dei nomi sono solo per la risoluzione dei conflitti, non per l'organizzazione delle classi. Utilizzare gli spazi dei nomi solo laddove sia logico utilizzarli, ad esempio dove ci si aspetta che abbiano conflitti di denominazione con altri progetti che potrebbero utilizzare il progetto, consentendo l'inclusione o l'esclusione di determinati spazi dei nomi con l'utilizzo delle istruzioni. È terribile avere un progetto con 3 o 4 o più spazi dei nomi usati di frequente, perché si traduce sempre in un numero ridicolo di istruzioni d'uso che è necessario aggiungere, aggiungere, aggiungere e aggiungere. Dividi i tuoi progetti.
Triynko,

31

Penso che lo standard, all'interno di .NET, sia quello di provare a farlo quando possibile, ma non di creare strutture inutilmente profonde solo per aderirvi come una regola dura. Nessuno dei miei progetti segue la regola dello spazio dei nomi == il 100% delle volte, a volte è solo più pulito / meglio uscire da tali regole.

In Java non hai scelta. Lo definirei un caso classico di ciò che funziona in teoria rispetto a ciò che funziona in pratica.


1
Direi "fallo quando vuoi davvero che qualcosa sia nel suo spazio dei nomi". Dovrebbe essere una decisione consapevole. Se i tuoi progetti sono adeguatamente isolati, dovrebbe essere uno spazio dei nomi per progetto. Se la tua classe si trova in uno spazio dei nomi, dovrebbe trovarsi in una cartella con quello spazio dei nomi O in una posizione della sottocartella che sia almeno specifica come lo spazio dei nomi. Una classe come Car.Ford.Fusion (se Car.Ford è il tuo unico spazio dei nomi) dovrebbe trovarsi in una cartella come Auto / Ford O più profonda come Auto / Ford / Berline, in modo tale che la cartella sia almeno specifica come lo spazio dei nomi. Basta non metterlo in auto / non correlato / Ford; è confuso.
Triynko,

25

@lassevk: sono d'accordo con queste regole e ne ho un'altra da aggiungere.

Quando ho classi nidificate, le divido ancora, una per file. Come questo:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

e

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

5

Direi di si.

Innanzitutto, sarà più facile trovare i file di codice effettivi seguendo gli spazi dei nomi (diciamo, quando qualcuno ti invia per e-mail uno stack di chiamate di eccezioni nudo). Se lasci che le tue cartelle non siano sincronizzate con gli spazi dei nomi, la ricerca di file in grandi codebase diventa stancante.

In secondo luogo, VS genererà nuove classi create in cartelle con lo stesso spazio dei nomi della struttura della cartella principale. Se decidi di nuotare contro questo, sarà solo un altro lavoro idraulico da fare ogni giorno quando aggiungi nuovi file.

Naturalmente, questo è ovvio che si dovrebbe essere prudenti su come va in profondità la gerarchia di cartelle / spazi dei nomi xis.


4

Sì dovrebbero, porta solo alla confusione altrimenti.


2

Qual è lo standard?

Non esiste uno standard ufficiale, ma convenzionalmente il modello di mappatura da cartella a spazio dei nomi è ampiamente utilizzato.

Nelle librerie di classi le cartelle di solito corrispondono alla struttura dello spazio dei nomi o è un miscuglio?

Sì, nella maggior parte delle librerie di classi le cartelle corrispondono allo spazio dei nomi per facilità organizzativa.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.