Freigeben über

Namespace-Namen

Hinweis

Dieser Inhalt wird mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines: Konventionen, Idiome und Muster für wiederverwendbare .NET-Bibliotheken, 2. Auflage nachgedruckt. Diese Ausgabe wurde 2008 veröffentlicht, und das Buch wurde seitdem in der dritten Ausgabe vollständig überarbeitet. Einige der Informationen auf dieser Seite sind möglicherweise veraltet.

Wie bei anderen Benennungsrichtlinien schafft das Ziel beim Benennen von Namespaces eine ausreichende Klarheit für den Programmierer, der das Framework verwendet, um sofort zu wissen, was der Inhalt des Namespaces wahrscheinlich ist. Die folgende Vorlage gibt die allgemeine Regel für die Benennung von Namespaces an:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Es folgen Beispiele:

Fabrikam.Math Litware.Security

✔️ Verwenden Sie einen Firmennamen als Präfix für Namespaces, um zu verhindern, dass Namespaces aus verschiedenen Unternehmen denselben Namen haben.

✔️ Verwenden Sie einen stabilen, versionsunabhängigen Produktnamen auf der zweiten Ebene eines Namespacenamens.

❌ VERWENDEN SIE KEINE Organisationshierarchien als Grundlage für Namen in Namespacehierarchien, da Gruppennamen innerhalb von Unternehmen tendenziell kurzlebig sind. Strukturieren Sie die Hierarchie der Namespaces für Gruppen von verwandten Technologien.

✔️ DO verwenden PascalCasing, und separieren Sie Namespace-Komponenten mit Punkten (z. B. Microsoft.Office.PowerPoint). Wenn Ihre Marke eine unkonventionelle Schreibweise verwendet, sollten Sie der von Ihrer Marke definierten Schreibweise folgen, auch wenn sie von der normalen Standardschreibweise abweicht.

✔️ ERWÄGEN SIE gegebenenfalls die Verwendung von Pluralnamespacenamen.

Verwenden Sie z. B. System.Collections statt System.Collection. Markennamen und Akronyme sind jedoch Ausnahmen von dieser Regel. Verwenden Sie z. B. System.IO statt System.IOs.

❌ Verwenden Sie nicht denselben Namen für einen Namespace und einen Typ in diesem Namespace.

Verwenden Sie beispielsweise nicht Debug als Namespacenamen und legen Sie dann eine Klasse namens Debug im selben Namespace fest. Mehrere Compiler erfordern, dass solche Typen voll qualifiziert sind.

Namespaces und Typnamenkonflikte

❌ Führen Sie keine generischen Typnamen wie Element, Node, Log, und Message ein.

Es gibt eine sehr hohe Wahrscheinlichkeit, dass dies zu Typnamenkonflikten in gängigen Szenarien führt. Sie sollten die generischen Typnamen (FormElement, XmlNode, EventLog, SoapMessage) qualifizieren.

Es gibt spezielle Richtlinien zum Vermeiden von Typennamenkonflikten für verschiedene Namespacekategorien.

  • Anwendungsmodell-Namespaces

    Namespaces, die zu einem einzelnen Anwendungsmodell gehören, werden sehr häufig zusammen verwendet, aber sie werden fast nie mit Namespaces anderer Anwendungsmodelle verwendet. Beispielsweise wird der System.Windows.Forms Namespace sehr selten zusammen mit dem System.Web.UI Namespace verwendet. Es folgt eine Liste bekannter Anwendungsmodellnamespacegruppen:

    System.Windows* System.Web.UI*

    ❌ GEBEN Sie nicht denselben Namen für Typen in Namespaces innerhalb eines einzelnen Anwendungsmodells.

    Fügen Sie beispielsweise keinen Typ namens Page zum Namespace System.Web.UI.Adapters hinzu, da der Namespace System.Web.UI bereits einen Typ namens Page enthält.

  • Infrastruktur-Namensräume

    Diese Gruppe enthält Namespaces, die während der Entwicklung allgemeiner Anwendungen selten importiert werden. Beispielsweise werden .Design Namespaces hauptsächlich beim Entwickeln von Programmiertools verwendet. Das Vermeiden von Konflikten mit Typen in diesen Namespaces ist nicht wichtig.

  • Kernnamespaces

    Kernnamespaces umfassen alle System Namespaces, ausgenommen Namespaces der Anwendungsmodelle und die Infrastrukturnamespaces. Kernnamespaces umfassen unter anderem, System, , System.IO, System.Xmlund System.Net.

    ❌ GEBEN SIE KEINE Typennamen an, die mit jedem Typ in den Core-Namespaces in Konflikt geraten würden.

    Verwenden Sie Stream z. B. niemals als Typnamen. Es würde mit einem sehr häufig verwendeten Typ in Konflikt geraten System.IO.Stream.

  • Technologie-Namensraumgruppen

    Diese Kategorie umfasst alle Namespaces mit denselben ersten beiden Namespaceknoten ((<Company>.<Technology>*), wie zum Beispiel Microsoft.Build.Utilities und Microsoft.Build.Tasks. Es ist wichtig, dass Typen, die zu einer einzigen Technologie gehören, nicht miteinander in Konflikt stehen.

    ❌ WEISEN SIE KEINE Typnamen zu, die mit anderen Typen innerhalb einer einzigen Technologie in Konflikt geraten würden.

    ❌ FÜHREN SIE KEINE Typnamenskonflikte zwischen Typen in Technologiebereichen und einem Anwendungsmodell-Namensraum ein (es sei denn, die Technologie soll nicht mit dem Anwendungsmodell verwendet werden).

© Teile 2005, 2009 Microsoft Corporation. Alle Rechte vorbehalten.

Nachdruck mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2. Auflage von Krzysztof Cwalina und Brad Abrams, veröffentlicht am 22. Okt 2008 von Addison-Wesley Professional als Teil der Microsoft Windows Development Series.

Siehe auch