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

https://stackoverflow.com/questions/4664

08-06-2019
|

Domanda

In uno dei progetti del mio team, abbiamo una libreria di classi che contiene molte sottocartelle nel progetto.

Nome del progetto e spazio dei nomi: MyCompany.Project.Section.

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

Cartella Vehicles ha lezioni in MyCompany.Project.Section.Vehicles spazio dei nomi
Cartella Clothing ha lezioni inMyCompany.Project.Section.Clothing spazio dei nomi
eccetera.

All'interno di questo stesso progetto c'è un'altra cartella non autorizzata

Cartella BusinessObjects ha lezioni in MyCompany.Project.Section spazio dei nomi

Ci sono alcuni casi come questo in cui le cartelle sono realizzate per "convenienza 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?

Soluzione

Inoltre, tieni presente che se utilizzi i modelli integrati per aggiungere classi a una cartella, per impostazione predefinita verrà inserita in uno spazio dei nomi che riflette la gerarchia delle cartelle.

Le lezioni saranno più facili da trovare e già questo dovrebbe essere un motivo sufficiente.

Le regole che seguiamo sono:

Il nome del progetto/assembly è uguale allo spazio dei nomi root, ad eccezione del finale .dll
L'unica eccezione alla regola di cui sopra è un progetto con un finale .Core, il .Core viene rimosso
Le cartelle equivalgono agli spazi dei nomi
Un tipo per file (classe, struttura, enum, delegato e così via) semplifica la ricerca del file corretto

Altri suggerimenti

NO.

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

Ho scoperto che il percorso più semplice e produttivo era avere un unico spazio dei nomi per progetto e tutte le classi vanno in quello spazio dei nomi.Sarai quindi libero di inserire i file della classe nelle cartelle di progetto che desideri.Non c'è alcun problema nell'aggiungere sempre istruzioni using all'inizio dei file poiché esiste un solo spazio dei nomi.

È importante organizzare i file sorgente in cartelle e secondo me è per questo che dovrebbero essere utilizzate tutte le cartelle.Richiedere che queste cartelle siano mappate anche agli spazi dei nomi non è necessario, crea più lavoro e ho scoperto che era effettivamente dannoso per l'organizzazione perché il carico aggiuntivo incoraggia la disorganizzazione.

Prendi questo avviso FxCop ad esempio:

CA1020:Evita 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 dump di nuovi file in una cartella Project.General generica o anche nella radice del progetto finché non si avranno quattro classi simili per giustificare la creazione di una nuova cartella.Succederà mai?

Ricerca di file

La risposta accettata dice "Le lezioni saranno più facili da trovare e questo da solo dovrebbe essere un motivo abbastanza valido".

Sospetto che la risposta si riferisca alla presenza di più spazi dei nomi in un progetto che non corrispondono alla struttura delle cartelle, piuttosto che a ciò che sto suggerendo, ovvero un progetto con un singolo spazio dei nomi.

In ogni caso, anche se 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 Esplora soluzioni di ricerca in Visual Studio.Anche questo non è un grosso problema secondo me.Non spendo nemmeno lo 0,1% del mio tempo di sviluppo nel problema di trovare file per giustificare l'ottimizzazione.

I nomi si scontrano

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ù semplice 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.Supponiamo che tu abbia due classi Rectangle definite in spazi dei nomi separati:

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

È possibile riscontrare un problema per cui un file di origine deve includere entrambi gli spazi dei nomi.Ora devi scrivere lo spazio dei nomi completo ovunque in quel file:

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

Oppure scherzare con qualche brutta istruzione using:

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 devi occuparti di un caso speciale quando un file utilizza entrambi i tipi.

utilizzando le dichiarazioni

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

contro

using Project1;

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

Modifica della struttura delle cartelle del progetto

Se le cartelle sono mappate sugli spazi dei nomi, il percorso della cartella del progetto viene effettivamente codificato in ciascun file di origine.Ciò significa che qualsiasi ridenominazione o spostamento di un file o di una cartella nel progetto richiede la modifica del contenuto effettivo del file.Sia la dichiarazione dello spazio dei nomi dei file in quella cartella sia le istruzioni using in tutta una serie di altri file che fanno riferimento alle classi in quella cartella.Sebbene le modifiche stesse siano banali con gli strumenti, di solito si traducono in un commit di grandi dimensioni costituito da molti file le cui classi non sono nemmeno cambiate.

Con un singolo spazio dei nomi nel progetto puoi modificare la struttura delle cartelle del progetto come preferisci senza che i file sorgente stessi vengano modificati.

Visual Studio esegue automaticamente il mapping dello spazio dei nomi di un nuovo file alla cartella del progetto in cui è stato creato

Sfortunatamente, ma trovo che il fastidio di correggere lo spazio dei nomi sia inferiore al fastidio di gestirli.Inoltre ho preso l'abitudine di copiare e incollare un file esistente anziché utilizzare Aggiungi->Nuovo.

Intellisense e browser degli oggetti

A mio avviso, il vantaggio più grande derivante dall'utilizzo di più spazi dei nomi in progetti di grandi dimensioni è avere un'organizzazione aggiuntiva durante la visualizzazione delle classi in qualsiasi strumento che visualizzi le classi in una gerarchia di spazi dei nomi.Anche la 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 perplesso o ritardato a causa della mancanza di questo, quindi non lo trovo un vantaggio abbastanza grande da giustificare più spazi dei nomi.

Anche se stessi scrivendo una grande libreria di classi pubbliche, allora io volevo probabilmente utilizzare più spazi dei nomi nel progetto in modo che l'assembly appaia pulito negli strumenti e nella documentazione.

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

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

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

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

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

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

Direi di sì.

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

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

Naturalmente, questo è ovvio che si dovrebbe essere prudenti riguardo alla profondità della gerarchia di cartelle/spazi dei nomi xis.

Sì, dovrebbero, altrimenti creerebbe solo confusione.

Qual è lo standard?

Non esiste uno standard ufficiale, ma convenzionalmente il modello di mappatura cartella-spazio dei nomi è quello più ampiamente utilizzato.

Nelle librerie di classe 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 comodità organizzativa.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow