Moet die dopgehou in'n oplossing pas die namespace?

Question

Moet die dopgehou in'n oplossing pas die namespace?

In een van my spanne projekte, ons het'n klas biblioteek wat baie sub-gidse in die projek.

Projek Naam en Namespace: MyCompany.Project.Section.

Binne hierdie projek, daar is verskeie dopgehou wat ooreenstem met die namespace afdeling:

• Gids Vehicles het klasse in die MyCompany.Project.Section.Vehicles namespace
• Gids Clothing het klasse in dieMyCompany.Project.Section.Clothing namespace
• ens.

Binne hierdie projek, is nog'n skelm gids

• Gids BusinessObjects het klasse in die MyCompany.Project.Section namespace

Daar is'n paar gevalle soos hierdie waar dopgehou word gemaak vir "organisatoriese gerief".

My vraag is:Wat is die standaard?In die klas biblioteke doen die dopgehou gewoonlik ooreenstem met die namespace struktuur of is dit'n gemengde sak?

Answer 1

Let ook op dat as jy die ingeboude templates gebruik om klasse by te voeg om 'n gids, dit sal by verstek word in 'n naamruimte wat die gids hiërargie weerspieël sit.

Die klasse sal makliker wees om te vind en dat alleen moet wees redes goed genoeg nie.

Die reëls wat ons volg is:

• naam Projek / vergadering is dieselfde as die wortel naamruimte, behalwe vir die DLL eindig
• enigste uitsondering op die bogenoemde reël is 'n projek met 'n .Core eindig, is die .Core uitgetrek
• Leer gelyk naamruimtes
• Een tipe per lêer (klas, struct, enum, delegeer, ens) maak dit maklik om die regte lêer te vind

Answer 2

Geen.

Ek het probeer om beide metodes op klein en groot projekte, beide met'n enkele (my) en'n span van die ontwikkelaars.

Ek het gevind dat die eenvoudigste en mees produktiewe roete was om'n enkele namespace per projek en al die klasse gaan in daardie namespace.Jy is dan vry om te sit in die klas lêers in wat die projek dopgehou wat jy wil.Daar is geen geknoei oor die byvoeging van die gebruik van state op die top van lêers al die tyd, want daar is net'n enkele namespace.

Dit is belangrik om te organiseer bron lêers in dopgehou en in my mening is dit is al wat dopgehou moet gebruik word vir.Vereis dat hierdie dopgehou ook'n kaart om te namespace is onnodig, die skep van meer werk, en ek gevind het, was eintlik skadelik vir die organisasie omdat die bykomende las moedig wanorde.

Neem hierdie FxCop waarskuwing byvoorbeeld:

CA1020:Vermy namespace met'n paar tipes
veroorsaak:'n namespace anders as die globale namespace bevat minder as vyf tipes https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Hierdie waarskuwing moedig die storting van nuwe lêers in'n generiese Projek.Algemene gids, of selfs die projek wortel totdat jy het vier soortgelyke klasse te regverdig skep'n nuwe gids.Sal dit ooit gebeur?

Die Vind Van Lêers

Die aanvaarde antwoord sê: "Die klasse sal makliker wees om te vind en wat alleen moet redes wees goed genoeg nie."

Ek vermoed die antwoord is verwys na die feit dat verskeie namespace in'n projek wat nie kaart van die gids struktuur, eerder as wat ek is wat daarop dui wat is'n projek met'n enkele namespace.

In elk geval, terwyl jy kan nie bepaal watter gids'n klas lêer is in van die namespace, jy kan dit vind deur gebruik te maak van Gaan Na die Definisie of die soek oplossing explorer boks in Visual Studio.Ook dit is nie regtig'n groot probleem in my opinie.Ek het nie bestee selfs 0.1% van my ontwikkeling tyd op die probleem van die vind van lêers te regverdig die optimalisering van dit.

Naam botsings

Seker die skep van verskeie namespace laat projek het twee klasse met dieselfde naam.Maar is dit regtig'n goeie ding?Is dit miskien makliker om net te weier dat dit moontlik?Sodat die twee klasse met dieselfde naam skep'n meer komplekse situasie waar 90% van die tyd dinge werk'n sekere manier en dan is jy skielik vind jy'n spesiale geval.Sê jy het twee Reghoek klasse gedefinieer in aparte namespace:

• klas Project1.Beeld.Reghoek
• klas Project1.Venster.Reghoek

Dit is moontlik om te tref'n kwessie wat'n bron lêer moet sluit beide namespace.Nou het jy om te skryf uit die volle namespace oral in die lêer:

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

Of gemors oor met'n paar nare met behulp van die verklaring:

using Rectangle = Project1.Window.Rectangle;

Met'n enkele namespace in jou projek, jy is gedwing om te kom met verskillende, en ek wil argumenteer meer beskrywende, name soos hierdie:

• klas Project1.ImageRectangle
• klas Project1.WindowRectangle

En gebruik is oral dieselfde, jy nie het om te gaan met'n spesiale geval wanneer'n lêer gebruik maak van beide tipes.

die gebruik van state

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;

Die gemak van nie hoef te voeg namespace al die tyd, terwyl die skryf van die kode.Dit is nie die tyd wat dit neem regtig, dit is die breek in die vloei van die feit dat om dit te doen en net in te vul-up lêers met baie van die gebruik van state - vir wat?Is dit die moeite werd?

Die verandering van die projek gids struktuur

As gidse is gekarteer te namespace dan die projek gids pad is effektief hard-gekodeerde in elke bron lêer.Dit beteken dat enige hernoem of beweeg van'n lêer of gids in die projek vereis werklike lêer inhoud te verander.Beide die namespace verklaring van lêers in die gids en die gebruik van state in'n hele klomp van die ander lêers wat verwysing klasse in die gids.Terwyl die veranderinge self is triviale met gereedskap, is dit gewoonlik die resultate in'n groot pleeg bestaan uit baie lêers wie se klasse het nog nie verander nie.

Met'n enkele namespace in die projek wat jy kan verander projek gids struktuur is egter jy wil, sonder enige bron lêers hulself verander.

Visual Studio outomaties kaarte die namespace van'n nuwe lêer om die projek gids dit is geskep in

Jammer, maar ek vind die moeite van die regstelling van die namespace is minder as die probleme van die hantering van hulle.Ook ek het in die gewoonte van die afskrif plak'n bestaande lêer eerder as die gebruik van Add->Nuwe.

Intellisense en Voorwerp Leser

Die grootste voordeel in my opinie van die gebruik van verskeie namespace in groot projekte is om ekstra organisasie wanneer die lees van klasse in enige gereedskap wat vertoon klasse in'n namespace hiërargie.Selfs dokumentasie.Dit is duidelik dat met net een namespace in die projek resultate in al die klasse vertoon word in'n enkele lys, eerder as gebreek in kategorieë.Maar ek persoonlik het nog nooit gestonk of vertraag word as gevolg van'n gebrek van hierdie, so ek vind dit nie'n groot genoeg voordeel te regverdig verskeie namespace.

Alhoewel as ek skryf'n groot openbare klas biblioteek dan het ek sou waarskynlik die gebruik van verskeie namespace in die projek sodat die vergadering kyk netjies in die gereedskap en dokumentasie.

Answer 3

Ek dink die standaard, binne NET, is om te probeer om dit te doen wanneer moontlik, maar onnodig diep strukture net om te voldoen aan dit as 'n harde reël te skep. Nie een van my projekte volg die naamruimte == struktuur reël 100% van die tyd, soms dit is net skoner / beter om uit te breek uit sodanige reëls.

In Java jy nie n keuse het. Ek wil noem dat 'n klassieke geval van wat werk in teorie vs wat werk in die praktyk.

Answer 4

@lassevk: Ek stem saam met hierdie reëls, en het 'n meer toe te voeg

.

Wanneer ek klasse het nes gemaak, ek nog verdeel hulle uit, een per lêer. Soos volg:

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

en

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

Answer 5

Ek sal ja sê.

In die eerste plek sal dit makliker wees om die werklike kode lêers te vind deur volgende neer die name spaces (sê, as iemand e-posse wat jy 'n blote uitsondering oproep stapel). As jy toelaat dat jou dopgehou gaan uit pas met naamruimtes, vind lêers in groot codebases word om uitputtend.

In die tweede plek VS sal nuwe klasse wat jy maak in dopgehou met dieselfde naam ruimte van sy moedermaatskappy lêergidsstruktuur genereer. As jy besluit om te swem teen hierdie, sal dit net nog 'n loodgieter werk om daagliks te doen wanneer die toevoeging van nuwe lêers.

Natuurlik is dit vanselfsprekend dat 'n mens konserwatief oor hoe diep XiS gids / naamruimte hiërargie gaan moet wees.

Answer 6

Ja hulle moet nie, lei net tot verwarring anders.

Answer 7

  

Wat is die standaard?

Daar is geen amptelike standaard maar konvensioneel die gids-tot-naamruimte kartering patroon is mees algemeen gebruik.

  

In die klas biblioteke nie die dopgehou gewoonlik ooreenstem met die naamruimte   struktuur of is dit 'n gemengde sak?

Ja, in die meeste klas biblioteke die dopgehou ooreenstem met die naamruimte vir organisatoriese gemak.