Namen von Namespaces

  • Artikel
  • 2 Minuten Lesedauer

Wie bei anderen Benennungsrichtlinien schafft das Ziel beim Benennen von Namespaces ausreichend 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 Benennungsnamespaces an:

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

Hier finden Sie einige Beispiele:

Fabrikam.Math Litware.Security

✔️ DO-Präfixnamenamen mit einem Firmennamen, um zu verhindern, dass Namespaces aus verschiedenen Unternehmen denselben Namen haben.

✔️ DO verwenden 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 eher kurzlebig sind. Organisieren Sie die Hierarchie von Namespaces um Gruppen verwandter Technologien.

✔️ DO verwenden PascalCasing und separate Namespacekomponenten mit Perioden (z. B. Microsoft.Office.PowerPoint). Wenn Ihre Marke nicht traditionelle Casing verwendet, sollten Sie der von Ihrer Marke definierten Casing folgen, auch wenn sie von der normalen Namespace-Casing abweicht.

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

Verwenden Sie z. B. System.Collections statt System.Collection. Markennamen und Akronyme sind jedoch Ausnahmen für diese Regel. Verwenden Sie z. B. System.IO statt System.IOs.

❌ DO NOT use the same name for a namespace and a type in that namespace.

Verwenden Debug Sie z. B. nicht als Namespacename, und geben Sie dann auch eine Klasse Debug namens im selben Namespace an. Mehrere Compiler erfordern, dass solche Typen voll qualifiziert werden.

Namespaces und Typnamenkonflikte

❌DO NOT einführung generische Typnamen wie , ElementNodeLogund Message.

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

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

  • Anwendungsmodellnamespaces

    Namespaces, die zu einem einzelnen Anwendungsmodell gehören, werden 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. Nachfolgend sehen Sie eine Liste bekannter Anwendungsmodellnamespacegruppen:

    System.Windows* System.Web.UI*

    ❌ Do not give the same name to types in namespaces within a single application model.

    Fügen Sie beispielsweise keinen Typ namens Page dem System.Web.UI.Adapters Namespace hinzu, da der System.Web.UI Namespace bereits einen Typ namens " Page.

  • Infrastrukturnamespaces

    Diese Gruppe enthält Namespaces, die während der Entwicklung allgemeiner Anwendungen selten importiert werden. Namespaces werden beispielsweise .Design 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.Xml, und System.Net.

    ❌ DO NOT give types names that would conflict with any type in the Core namespaces.

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

  • Technologienamespacegruppen

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

    ❌ DO NOT assign type names that would conflict with other types within a single technology.

    ❌ DO NOT führt Typennamenkonflikte zwischen Typen in Technologienamespaces und einem Anwendungsmodellnamespace 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, 2nd Edition von Krzysztof Cwalina und Brad Abrams, veröffentlicht am 22. Oktober 2008 durch Addison-Wesley Professional als Teil der Microsoft Windows Development Series.

Weitere Informationen