Namen von Namespaces
Aktualisiert: November 2007
Der für einen Namespace gewählte Name sollte die Funktionalität angeben, die von den Typen im Namespace verfügbar gemacht wird. Beispielsweise enthält der System.Net.Sockets-Namespace Typen, die Entwicklern die Verwendung von Sockets für die netzwerkübergreifende Kommunikation ermöglichen.
Das allgemeine Format für einen Namespacenamen lautet wie folgt:
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
Beispiel: Microsoft.WindowsMobile.DirectX.
Verwenden Sie Organisationshierarchien als Grundlage für Namen in Namespacehierarchien, weil Gruppennamen in Unternehmen häufig kurzlebig sind.
Der Namespacename ist ein langlebiger und unveränderlicher Bezeichner. Während der Entwicklung von Organisationen sollten Änderungen nicht dazu führen, dass der Namespacename veraltet ist.
Konflikte zwischen Namespace- und Typnamen
Wenn Sie einen Namespace- oder Typnamen wählen, der einen Konflikt mit einem vorhandenen Namen verursacht, müssen Bibliotheksbenutzer Verweise auf die betroffenen Elemente qualifizieren. Dies sollte in den meisten Entwicklungsszenarien nicht der Fall sein.
Einige der Richtlinien, die in diesem Abschnitt vorgestellt werden, sind für die folgenden Kategorien von Namespaces relevant:
Anwendungsmodellnamespaces
Infrastrukturnamespaces
Kernnamespaces
Technologienamespacegruppen
Die Namespaces in einem Anwendungsmodell stellen den für eine Klasse von Anwendungen spezifischen Satz von Funktionalität bereit. Beispielsweise stellen die Typen in den System.Windows.Forms-Namespaces die Funktionalität bereit, die zum Schreiben von Windows Forms-Clientanwendungen erforderlich ist. Die Typen in den System.Web-Namespaces unterstützen das Schreiben webbasierter Serveranwendungen. Im Allgemeinen werden Namespaces aus unterschiedlichen Anwendungsmodellen nicht in derselben Anwendung verwendet. Daher ist die Wahrscheinlichkeit gering, dass Namenskonflikte die Entwickler betreffen, die Ihre Bibliothek verwenden.
Infrastrukturanwendungen stellen spezielle Unterstützung bereit, und auf sie wird in Programmcode selten verwiesen. Beispielsweise werden die Typen in *.Designer-Namespaces von Programmentwicklungstools verwendet. Die *.Permissions-Namespaces sind ein weiteres Beispiel für Infrastrukturnamespaces. Die Wahrscheinlichkeit ist gering, dass Namenskonflikte mit Typen in Infrastrukturnamespaces von den Entwicklern berücksichtigt werden müssen, die Ihre Bibliothek verwenden.
Die Kernnamespaces sind die System.*-Namespaces (außer den Anwendungs- und Infrastrukturnamespaces). Beispiele für Kernnamespaces sind System und System.Text. Vermeiden Sie unbedingt Namenskonflikte mit Typen in den Kernnnamespaces.
Die Namespaces für eine bestimmte Technologie verfügen über dieselben Bezeichner der ersten und zweiten Ebene (Company.technology.*). Vermeiden Sie Namenskonflikte innerhalb einer Technologie.
Richtlinien für Anwendungsnamespaces
Legen Sie nicht für Typen in Namespaces in einem einzigen Anwendungsmodell den gleichen Namen fest.
Wenn Sie z. B. eine Bibliothek spezieller Steuerelemente schreiben, die von Windows Forms-Anwendungsentwicklern verwendet werden sollen, führen Sie keinen Typ mit dem Namen Checkbox ein, weil ein Typ mit diesem Namen bereits für das Anwendungsmodell vorhanden ist (CheckBox).
Richtlinien für Kernnamespaces
Legen Sie für Typen keine Namen fest, die zu einem Konflikt mit einem Typ in den Kernnamespaces führen.
Verwenden Sie z. B. nicht Directory als Typname, da dies zu einem Konflikt mit dem Directory-Typ führt.
Richtlinien für Technologienamespaces
Führen Sie keine Typnamenskonflikte zwischen Typen in Technologienamespaces und einem Anwendungsmodellnamespace ein (es sei denn, die Technologie ist nicht für die Verwendung in dem Anwendungsmodell vorgesehen).
Copyright für einzelne Teile 2005 Microsoft Corporation. Alle Rechte vorbehalten.
Copyright für einzelne Teile Addison-Wesley Corporation. Alle Rechte vorbehalten.
Weitere Informationen zu Entwurfsrichtlinien finden Sie im Buch "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" von Krzysztof Cwalina und Brad Abrams, veröffentlicht von Addison-Wesley, 2005.