Namen von Namespaces
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 , Element
Node
Log
und 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
, ) SoapMessage
qualifizieren.
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
, undSystem.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>*
, zMicrosoft.Build.Utilities
. B. undMicrosoft.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.