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.