Nu.
Am incercat ambele metode pe proiecte mici si mari, atat cu single (eu) cat si cu o echipa de dezvoltatori.
Am descoperit că calea cea mai simplă și cea mai productivă a fost aceea de a avea un singur spațiu de nume pe proiect și toate clasele să intre în acel spațiu de nume. Sunteți liberi să puneți fișierele de clasă în folderul de proiect dorit. Nu există nici o problemă cu privire la adăugarea de declarații în partea de sus a fișierelor tot timpul, deoarece există doar un singur spațiu de nume.
Este important să organizați fișierele sursă în foldere și, după părerea mea, că toate folderele ar trebui folosite. Solicitarea ca aceste foldere să fie de asemenea hărțuită în spațiile de nume nu este necesară, creează mai multă muncă și am constatat că este într-adevăr dăunătoare pentru organizare, deoarece povara adăugată încurajează dezorganizarea.
Luați acest avertisment FxCop, de exemplu:
CA1020: Evitați spațiile de nume cu câteva tipuri
Cauza: Un spațiu de nume, altul decât spațiul de nume global, conține mai puțin de cinci tipuri
https://msdn.microsoft.com/en-gb/library/ms182130.aspx
Acest avertisment încurajează eliminarea de noi fișiere într-un director generic de proiect, general sau chiar rădăcina proiectului până când aveți patru clase similare pentru a justifica crearea unui nou folder. Se va întâmpla asta vreodată?
Găsirea fișierelor
Răspunsul acceptat spune că "clasele vor fi mai ușor de găsit și că singurele ar trebui să fie motive suficiente".
Bănuiesc că răspunsul se referă la existența mai multor spații de nume într-un proiect care nu se referă la structura de directoare, mai degrabă decât ceea ce sugerez, care este un proiect cu un singur spațiu de nume.
În orice caz, în timp ce nu puteți determina care folder este un fișier de clasă din spațiul de nume, îl puteți găsi utilizând Go To Definition sau caseta de explorare a soluției de căutare din Visual Studio. De asemenea, acest lucru nu este într-adevăr o problemă importantă în opinia mea. Nu cheltuiesc nici măcar 0,1% din timpul meu de dezvoltare pentru a găsi fișiere pentru a justifica optimizarea.
Condamnările cu nume
Sigur creând mai multe spații de nume permite proiectului să aibă două clase cu același nume. Dar este chiar un lucru bun? Poate este mai ușor să renunți la această posibilitate? Permiterea a două clase cu același nume creează o situație mai complexă în care 90% din timp lucrurile funcționează într-un anumit mod și apoi dintr-o dată găsiți că aveți un caz special. Spuneți că aveți două clase de Rectangle definite în spații de nume separate:
- clasa Project1.Image.Rectangle
- clasa Project1.Window.Rectangle
Este posibil să apară o problemă pe care un fișier sursă trebuie să includă ambele spații de nume. Acum trebuie să scrieți spațiul de nume complet peste tot în fișierul respectiv:
var rectangle = new Project1.Window.Rectangle();
Sau mizerie cu unele declarație urât folosind:
using Rectangle = Project1.Window.Rectangle;
Cu un singur spațiu de nume în proiectul dvs. sunteți obligat să veniți cu alții și aș susține nume mai descriptive, cum ar fi:
- clasa Project1.ImageRectangle
- clasa Project1.WindowRectangle
Și utilizarea este aceeași peste tot, nu trebuie să vă ocupați de un caz special atunci când un fișier utilizează ambele tipuri.
using statements
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;
Usurinta de a nu trebui sa adaugati spatiu de nume in timp ce scrieti codul. Nu este timpul să dureze într-adevăr, este pauza în fluxul de a avea de a face acest lucru și doar umplerea fișierelor cu o mulțime de declarații folosind - pentru ce? Merita?
Changing project folder structure
Dacă folderele sunt mapate în spațiile de nume, calea directorului de proiect este codificată în mod eficient în fiecare fișier sursă. Aceasta înseamnă că orice redenumire sau mutare a unui fișier sau a unui dosar în proiect necesită schimbarea conținutului fișierului real. Atât declarația spațiului de nume al fișierelor din acel dosar, cât și folosirea instrucțiunilor într-o grămadă de alte fișiere care fac referire la clasele din acel dosar. În timp ce schimbările în sine sunt banale cu scule, rezultă de obicei o comitet mare constând din multe fișiere ale căror clase nu s-au schimbat nici măcar.
Cu un singur spațiu de nume în proiect puteți schimba structura folderului de proiect oricum doriți fără ca fișierele sursă să fie modificate.
Visual Studio automatically maps the namespace of a new file to the project folder it's created in
Unfortunate, but I find the hassle of correcting the namespace is less than the hassle of dealing with them. Also I've got into the habit of copy pasting an existing file rather than using Add->New.
Intellisense and Object Browser
Cel mai mare beneficiu, în opinia mea, de a folosi mai multe spații de nume în proiecte mari este organizarea suplimentară atunci când vizionează clase în orice unealtă care afișează clase într-o ierarhie a denumirilor. Chiar și documentația. Evident, având doar un singur spațiu de nume în rezultatele proiectului, toate clasele se afișează într-o singură listă și nu se clasifică în categorii. Cu toate acestea personal nu am fost niciodată lovit sau întârziat din cauza lipsei acestui lucru, așa că nu-i găsesc un beneficiu destul de mare pentru a justifica mai multe spații de nume.
Deși dacă scriam o bibliotecă de clasă publică mare, atunci probabil că ar folosi mai multe spații de nume în proiect, astfel încât ansamblul să părea îngrijit în scule și documentație.