2009-02-02 13 views
75

Ich habe versucht, mehr über die C# Sprache zu lernen, aber ich habe nicht in der Lage gewesen, eine Situation zu sehen, wo ein Namespace-Aliasing wieC# Namespace Alias ​​- was ist der Sinn?

using someOtherName = System.Timers.Timer; 

Es scheint mir, dass es nur mehr Verwirrung würde hinzufügen, verwenden würde um die Sprache zu verstehen. Könnte jemand bitte erklären.

Dank

+4

Wie wäre es mit einem systemweiten 'using int = System.Int32' in C#? Nützlich, oder? Es ist die gleiche Verwendung, die anderswo genutzt werden kann. – nawfal

+0

@nawfal Ich glaube, Typ-Aliase sind nicht exportierbar. Das bedeutet, dass Sie etwas wie 'using int = System.Int32' nicht definieren können und es an anderen Stellen als der deklarierenden Datei verwenden können. Also kann dieser "int" zu "Int32" Alias ​​entweder durch andere Mittel erreicht werden oder ist eine spezielle Sache im Compiler/Runtime. – KFL

+0

@ KFL, das ist wahr, aber der Vorteil, den beide bieten, ist von der gleichen Natur. – nawfal

Antwort

121

, dass ein Typ alias ist, kein Namespace alias; es ist sinnvoll, eindeutig zu machen - zum Beispiel gegen:

using WinformTimer = System.Windows.Forms.Timer; 
using ThreadingTimer = System.Threading.Timer; 

(ps: danke für die Wahl von Timer ;-P)

Andernfalls, wenn Sie Ihnen beide System.Windows.Forms.Timer und System.Timers.Timer in der gleichen Datei verwenden‘ d muss immer die vollständigen Namen angeben (da Timer könnte verwirrend sein).

Es spielt auch eine Rolle mit extern Aliase für die Verwendung von Typen mit dem gleichen voll qualifizierten Typnamen aus verschiedenen Baugruppen - selten, aber nützlich, um unterstützt zu werden.


Eigentlich kann ich eine andere Verwendung finden: Wenn Sie einen schnellen Zugriff auf eine Art wollen, aber nicht wollen, dass eine regelmäßige using verwenden, da Sie nicht einige widersprüchliche Erweiterungsmethoden importieren kann ... ein wenig verworren , aber ... hier ist ein Beispiel ...

namespace RealCode { 
    //using Foo; // can't use this - it breaks DoSomething 
    using Handy = Foo.Handy; 
    using Bar; 
    static class Program { 
     static void Main() { 
      Handy h = new Handy(); // prove available 
      string test = "abc";    
      test.DoSomething(); // prove available 
     } 
    } 
} 
namespace Foo { 
    static class TypeOne { 
     public static void DoSomething(this string value) { } 
    } 
    class Handy {} 
} 
namespace Bar { 
    static class TypeTwo { 
     public static void DoSomething(this string value) { } 
    } 
} 
+8

Es kann verwendet werden, um entweder Namespaces oder Typnamen zu aliasieren. –

+1

@Sean: ja, aber das angegebene Beispiel war zu einem Typ –

+0

@lupefiasco: bequem von der OP zu wählen "System.Timers.Timer"; -p –

3

Es ist sehr nützlich, wenn Sie mehrere Klassen mit dem gleichen Namen haben in mehreren Namespaces enthalten. Zum Beispiel ...

namespace Something.From.SomeCompanyA { 
    public class Foo { 
     /* ... */ 
    } 
} 

namespace CompanyB.Makes.ThisOne { 
    public class Foo { 
     /* ... */ 
    } 
} 

Sie Aliasnamen verwenden, kann der Compiler glücklich zu machen und die Dinge klarer für Sie und andere in Ihrem Team zu machen:

using CompanyA = Something.From.CompanyA; 
using CompanyB = CompanyB.Makes.ThisOne; 

/* ... */ 

CompanyA.Foo f = new CompanyA.Foo(); 
CompanyB.Foo x = new CompanyB.Foo(); 
6

ich es immer in Situationen wie diese verwenden

using Utility = MyBaseNamespace.MySubNamsepace.Utility; 

wo Utility sonst einen anderen Kontext (wie MyBaseNamespace.MySubNamespace.MySubSubNamespace.Utility) haben würde, aber ich erwarte/Utility lieber zu, dass man p immer Punkt Gelenkklasse.

6

Kürze.

Es gibt Zusatzvorteile, um Klarheit zwischen Namespaces zu schaffen, die Typennamen teilen, aber im Wesentlichen ist es nur Zucker.

+0

Es zeigt deutlich, welches Symbol Sie verwenden. Es ist nicht nur Zucker, sondern ein bisschen ausführlich (wenn Sie keinen neuen Namen definieren möchten). –

21

Ich benutze es, wenn ich mehrere Namespaces mit widersprüchlichen Unternamensraum und/oder Objektnamen haben Sie gerade wie könnte etwas tun [als Beispiel]:

using src = Namespace1.Subspace.DataAccessObjects; 
using dst = Namespace2.Subspace.DataAccessObjects; 

... 

src.DataObject source = new src.DataObject(); 
dst.DataObject destination = new dst.DataObject(); 

die sonst geschrieben werden müssten:

Es spart eine Menge Tipparbeit und kann verwendet werden, um Code viel einfacher zu lesen.

3

Wir haben Namespace-Aliase für alle unsere Namespaces definiert. Dies macht es sehr einfach, zu sehen, wo eine Klasse kommt, z:

using System.Web.WebControls; 
// lots of other using statements 

// contains the domain model for project X 
using dom = Company.ProjectX.DomainModel; 
// contains common web functionality 
using web = Company.Web; 
// etc. 

und

// User from the domain model 
dom.User user = new dom.User(); 
// Data transfer object 
dto.User user = new dto.User(); 
// a global helper class 
utl.SomeHelper.StaticMethod(); 
// a hyperlink with custom functionality 
// (as opposed to System.Web.Controls.HyperLink) 
web.HyperLink link = new web.HyperLink(); 

Wir haben einige Richtlinien festgelegt, wie die Aliase genannt werden müssen, und jeder wird mit ihnen.

+1

Finden Sie nicht, dass der Alias ​​mehr mit dem Kontext zu tun hat, in dem er verwendet wird als der physische Ort des Objekts? – BenAlabaster

13

Neben den genannten Beispielen Typ-Aliasnamen (anstelle von Namespace-Aliase) kann nützlich sein, wenn sie wiederholt generische Typen verweisen:

Dictionary<string, SomeClassWithALongName> foo = new Dictionary<string, SomeClassWithALongName>(); 

private void DoStuff(Dictionary<string, SomeClassWithALongName> dict) {} 

Versus:

using FooDict = Dictionary<string, SomeClassWithALongName>; 

FooDict foo = new FooDict(); 

private void DoStuff(FooDict dict) {} 
1

ich die Aliase finden sehr nützlich in Komponententests. Wenn Sie Unit-Tests schreiben, ist es üblich, das Thema zu erklären, zu testen, wie

MyClass myClassUT; 

myClassUT, den Gegenstand U nder T est. Aber was, wenn Sie für ein Unit-Tests schreiben statische Klasse mit statischen Methoden? Dann können Sie einen Alias ​​wie folgt erstellen:

using MyStaticClassUT = Namespace.MyStaticClass; 

dann Sie Ihre Unit-Tests wie folgt schreiben können:

public void Test() 
{ 
    var actual = MyStaticClassUT.Method(); 
    var expected = ... 
} 

und man nie aus den Augen verlieren, was das Thema im Test ist.

2

In einer Hinsicht ist es sehr praktisch beim Programmieren in Visual Studio.

Anwendungsfall: Sagen wir, ich muss nur ein paar Klassen verwenden, z. SqlConnection aus einem Namespace System.Data. Im Normal Natürlich werde ich importieren Sie die System.Data.SqlClient Namespace an der Spitze der * CS-Datei wie folgt:

using System.Data; 

Jetzt auf meine Intellisense aussehen. Es ist stark mit vielen Klassen zur Auswahl aus dem Code-Editor eingegeben. Ich werde nicht gar ganze Reihe von Klassen verwenden:

enter image description here

So würde ich lieber einen Alias ​​an der Spitze meines * CS-Datei verwenden und eine klare intellisense Ansichten:

using SqlDataCon = System.Data.SqlClient.SqlConnection 

Schauen Sie sich jetzt meine Intellisense-Ansicht an. Es ist super klar und super sauber.

enter image description here

0

Ein Grund weiß ich; Sie können kürzere Namen verwenden, wenn Namenskonflikte aus importierten Namespaces auftreten. Beispiel:

Wenn Sie erklärt using System.Windows.Forms; und using System.Windows.Input; in der gleichen Datei, wenn Sie gehen für den Zugriff auf ModifierKeys Sie können feststellen, dass der Name ModifierKeys in sowohl den System.Windows.Forms.Control und System.Windows.Input Namensräume. Also, indem Sie using Input = System.Windows.Input; deklarieren können Sie dann System.Windows.Input.ModifierKeys über bekommen.

Ich bin kein C# Buff, aber Alias-Namensraum scheint mir "Best Practice" zu sein. Auf diese Weise wissen Sie, was Sie bekommen und müssen immer noch nicht viel mehr tippen.