Namen von Namespaces

  • Artikel

Hinweis

Diese Inhalte wurden mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines nachgedruckt: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. 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 auch sollen Programmierer*innen, die das Framework nutzen, anhand der Benennung von Namespaces sofort den wahrscheinlichen Inhalt des Namespaces erkennen können. Die folgende Vorlage legt die allgemeine Regel für die Benennung von Namespaces fest:

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

Hier finden Sie einige Beispiele:

Fabrikam.Math Litware.Security

✔️ VERWENDEN SIE als Präfix für Namespacenamen einen Firmennamen, damit Namespaces verschiedener Unternehmen nicht denselben Namen aufweisen.

✔️ VERWENDEN SIE auf der zweiten Ebene eines Namespacenamens einen beständigen, versionsunabhängigen Produktnamen.

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

✔️ VERWENDEN SIE die PascalCasing-Konvention, und trennen Sie Namespacekomponenten mit Punkten (z. B. Microsoft.Office.PowerPoint). Wenn Ihre Marke eine unübliche Groß-/Kleinschreibung verwendet, sollten Sie die von Ihrer Marke definierte Groß-/Kleinschreibung befolgen, auch wenn diese von der normalen Groß-/Kleinschreibung des Namespaces abweicht.

✔️ ERWÄGEN SIE die Verwendung von Pluralnamespacenamen, wo dies angebracht ist.

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

❌ VERWENDEN SIE NICHT denselben Namen für einen Namespace und einen Typ in diesem Namespace.

Sie sollten z. B. nicht Debug als Namespacenamen verwenden und dann eine Klasse namens Debug im selben Namespace bereitstellen. Verschiedene Compiler setzen voraus, dass solche Typen vollständig qualifiziert sind.

Namespaces und Typnamenkonflikte

❌ FÜHREN SIE KEINE generischen Typnamen wie Element, Node, Log und Message ein.

Die Wahrscheinlichkeit, dass dies in gängigen Szenarien zu Konflikten mit Typnamen führt, ist sehr hoch. Sie sollten die generischen Typnamen qualifizieren (FormElement, XmlNode, EventLog, SoapMessage).

Für verschiedene Kategorien von Namespaces gibt es spezielle Richtlinien zur Vermeidung von Typnamenkonflikten.

  • Namespaces für Anwendungsmodelle

    Namespaces, die einem einzigen Anwendungsmodell angehören, werden sehr oft zusammen verwendet, aber fast nie mit Namespaces anderer Anwendungsmodelle. Beispielsweise wird der Namespace System.Windows.Forms sehr selten zusammen mit dem Namespace System.Web.UI verwendet. Im Folgenden finden Sie eine Liste der bekannten Namespacegruppen für Anwendungsmodelle:

    System.Windows* System.Web.UI*

    ❌ Benennen Sie Typen in Namespaces innerhalb eines einzigen Anwendungsmodells NICHT gleich.

    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.

  • Infrastrukturnamespaces

    Diese Gruppe enthält Namespaces, die bei der Entwicklung gängiger Anwendungen selten importiert werden. Zum Beispiel werden .Design-Namespaces hauptsächlich bei der Entwicklung von Programmiertools verwendet. Die Vermeidung von Konflikten mit Typen in diesen Namespaces ist weniger wichtig.

  • Grundlegende Namespaces

    Zu den grundlegenden Namespaces gehören alle System-Namespaces, mit Ausnahme der Namespaces für Anwendungsmodelle und die Infrastrukturnamespaces. Zu den grundlegenden Namespaces gehören unter anderem System, System.IO, System.Xml und System.Net.

    ❌ Geben Sie den Typen KEINE Namen, die zu einem Konflikt mit Typen in den grundlegenden Namespaces führen würden.

    Verwenden Sie z. B. Stream niemals als Typnamen. Dieser Name steht in Konflikt mit System.IO.Stream, einem sehr häufig verwendeten Typ.

  • Technologienamespacegruppen

    Zu dieser Kategorie gehören alle Namespaces, bei denen die ersten beiden Namespaceknoten (<Company>.<Technology>*) identisch sind, z. B. Microsoft.Build.Utilities und Microsoft.Build.Tasks. Es ist wichtig, dass die Typen innerhalb einer einzelnen Technologie nicht zueinander in Konflikt stehen.

    ❌ Vergeben Sie KEINE Typnamen, die mit anderen Typen innerhalb einer einzigen Technologie in Konflikt stehen.

    ❌ FÜHREN SIE KEINE Typnamenkonflikte zwischen Typen in Technologienamespaces und einem Anwendungsmodellnamespace ein (es sei denn, die Technologie ist nicht für die Verwendung mit dem Anwendungsmodell vorgesehen).

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