Det vanligaste sättet VB.NET namnutrymmen används av de flesta programmerare är att berätta kompilatorn vilka .NET Framework-bibliotek som behövs för ett visst program. När du väljer en "mall" för ditt projekt (till exempel "Windows Forms Application") är en av sakerna att du väljer är den specifika uppsättningen av namnutrymmen som kommer att refereras automatiskt i din projekt. Detta gör koden i de namnområdena tillgängliga för ditt program.
Exempelvis är några av namnområdena och de faktiska filerna de finns i en Windows Forms-applikation:
System> i System.dll
Systemet. Data> i System. Data.dll
Systemet. Distribution> System. Deployment.dll
Systemet. Ritning> System. Drawing.dll
Systemet. Windows. Blanketter> System. Windows. Forms.dll
Du kan se (och ändra) namnutrymmen och referenser för ditt projekt i projektegenskaperna under referenser flik.
Detta sätt att tänka på namnområden gör att de verkar vara samma sak som "kodbibliotek", men det är bara en del av idén. Den verkliga fördelen med namnområden är organisation.
De flesta av oss kommer inte att få chansen att skapa en ny namnutrymmeshierarki eftersom det vanligtvis bara görs en gång ”i början” för ett stort och komplicerat kodbibliotek. Men här kommer du att lära dig att tolka namnområdena som du kommer att bli ombedd att använda i många organisationer.
Vad namnområden gör
Namnområden gör det möjligt att organisera de tiotusentals .NET Framework-objekten och alla objekt som VB-programmerare skapar i projekt också, så att de inte kolliderar.
Om du till exempel söker .NET efter en Färg objekt hittar du två. Det finns en Färg objekt i båda:
Systemet. Teckning
Systemet. Windows. Media
Om du lägger till en import uttalande för båda namnområdena (en referens kan också vara nödvändig för projektegenskaperna) ...
Importsystem. Teckning
Importsystem. Windows. Media
... sedan ett uttalande som ...
Dim en som färg
... kommer att flaggas som ett fel med anteckningen "Färg är tvetydig" och. NET påpekar att båda namnområdena innehåller ett objekt med det namnet. Den här typen av fel kallas en "namnet kollision."
Det här är det verkliga skälet till "namnutrymmen" och det är också hur namnutrymmen används i andra teknologier (som XML). Namnområden gör det möjligt att använda samma objektnamn, t.ex. Färg, när namnet passar och fortfarande håller saker organiserade. Du kan definiera en Färg objekt i din egen kod och hålla den skild från dem i .NET (eller koden för andra programmerare).
Namnområdet MyColor
Offentlig klassfärg
Underfärg ()
' Göra någonting
Avsluta under
Slutklass
Slut namnområde
Du kan också använda Färg objekt någon annanstans i ditt program så här:
Dim c Som ny MyColor. Färg
c. Färg()
Innan du går in på några av de andra funktionerna ska du vara medveten om att varje projekt finns i ett namnområde. VB.NET använder namnet på ditt projekt (WindowsApplication1 för ett standardformulärsprogram om du inte ändrar det) som standardnamnområde. För att se detta, skapa ett nytt projekt (vi använde namnet NSProj och kolla verktyget Object Browser):
- Klick Här för att visa illustrationen
- Klicka på Tillbaka knappen i din webbläsare för att återvända
Objektwebbläsaren visar det nya projektnamnsområdet (och de automatiskt definierade objekten i det) tillsammans med .NET Framework-namnutrymmen. Denna förmåga hos VB.NET att göra dina objekt lika med .NET-objekt är en av nycklarna till kraften och flexibiliteten. Till exempel är det därför Intellisense visar dina egna objekt så snart du definierar dem.
För att sätta igång ett hack, låt oss definiera ett nytt projekt (Vi heter vårt NewNSProj i samma lösning (använd Fil > Lägg till > Nytt projekt ...) och kodar ett nytt namnutrymme i det projektet. Och bara för att göra det roligare, låt oss lägga det nya namnutrymmet i en ny modul (vi namngjorde det NewNSMod). Och eftersom ett objekt måste kodas som en klass har vi också lagt till ett klassblock (benämnt NewNSObj). Här är koden och Lösningsutforskaren för att visa hur den passar ihop:
- Klick Här för att visa illustrationen
- Klicka på Tillbaka knappen i din webbläsare för att återvända
Eftersom din egen kod är "precis som ramkod", är det nödvändigt att lägga till en referens till NewNSMod i NSProj att använda objektet i namnområdet, även om de är i samma lösning. När det är gjort kan du förklara ett objekt i NSProj baserat på metoden i NewNSMod. Du måste också "bygga" projektet så att ett faktiskt objekt finns att referera.
Dim o As New NewNSProj. AVBNS.NewNSMod. NewNSObj
o. AVBNSMethod ()
Det är ganska en Dämpa uttalande dock. Vi kan förkorta det genom att använda en import uttalande med ett alias.
Import NS = NewNSProj. AVBNS.NewNSMod. NewNSObj
...
Dim o Som ny NS
o. AVBNSMethod ()
Klicka på Kör-knappen visar MsgBox från AVBNS-namnområdet "Hej! Det fungerade!"
När och varför man ska använda namnområden
Allt hittills har egentligen bara varit syntax - kodning regler som du måste följa i med hjälp av namnutrymmen. Men för att verkligen dra fördel, behöver du två saker:
- Ett krav på namnutrymme i första hand. Du behöver mer än bara ett "Hello World" -projekt innan organisationen av namnområden börjar lönas.
- En plan att använda dem.
I allmänhet, Microsoft rekommenderar att du organiserar organisationens kod med en kombination av ditt företagsnamn med produktnamnet.
Så om du till exempel är programvaruarkitekt för Dr. No's Nose Knows Plastic Surgery, kanske du vill organisera dina namnutrymmen som ...
DRNo
Consulting
ReadTheirWatchNChargeEm
TellEmNuthin
Kirurgi
ElephantMan
MyEyeLidsRGone
Detta liknar .NETs organisation ...
Objekt
Systemet
Kärna
IO
Linq
Data
odbc
sql
Namnområdena för flera nivåer uppnås genom att bara häcka namnutrymme-blocken.
Namnområde DRNo
Namnrymdskirurgi
Namnområde MyEyeLidsRGone
"VB-kod
Slut namnområde
Slut namnområde
Slut namnområde
eller
Namnområde DRNo. Kirurgi. MyEyeLidsRGone
"VB-kod
Slut namnområde