| 

.NET C# Java Javascript Exception

2
In Visual Basic werden die Namespaces über den Projektnamen für Klassen in der Regel automatisch vergeben. Das klappt in der Regel ganz gut. Nun möchte ich aber meine Klassen und Steuerelemente in unterschiedlichen Namespaces selber ordnen. Die Zuordnung eines Namespace kann sehr einfach erfolgen und bezieht sich dann auf die darin enthaltene Klasse. Auch wenn sich die Klassen in unterschiedlichen Dateien befinden, kann ich diese dem gleichen Namensraum oder auch unterschiedlichen Namensräumen zuordnen.

Namespace Funktionalität
Class …
End Class
End Namespace


Auch in einer einzelnen Datei lassen sich so mehrere Klassen einem bestimmten Namespace zuordnen.

Namespace Funktionalität
Class …
End Class
Class …
End Class
End Namespace


Das ganze soll nun so ausgebaut werden, das ich den Hauptnamensraum mit dem Firmennamen vorgebe.

Namespace Firma.Funktionalität
...
End Namespace


Jetzt möchte ich die Funktionalität weiter gliedern, und habe nun die Möglichkeit Namespaces mit der vollen Punkthierarchie anzugeben oder die Namespace-Konstrukte zu schachteln.

Namespace Firma
Namespace Funktionalität

End Namespace
End Namespace


Ist es besser, generell mit der Schachtelung oder der Punktsyntax zu arbeiten? Und welche Auswirkungen haben Änderungen an den Namen der Namensräume, wenn Namensräume später umgeordnet oder umbenannt werden müssen? Welche Funktionen zu Refactoring greifen in einem solchen Fall und wo sind manuelle Nachbearbeitungen erforderlich? Gibt es generell Empfehlungen, wieviele Namensraumebenen man generell definieren sollte?
News:
19.06.2012
Interista 11 2
1 Antwort
0
Die geschachtelte und die Punkt-Syntax sind im Ergebnis äquivalent, wie auch die Beispiele auf http://msdn.microsoft.com/de-de/library/dfb3cx8s.aspx verdeutlichen. Die geschachtelte Syntax bietet Dir theoretisch die Möglichkeit, in einer Datei sowohl eine Klasse in Firma als auch eine in Firma.Funktionalität anzulegen. Davon würde ich aber abraten - eine Klasse pro Datei sollte die Regel sein. Somit ist mein Favorit die Punktsyntax, die ja auch die Code-Templates im Visual Studio erzeugen.

Die Refactoring-Unterstützung für Namensräume in Visual Studio ist nach meiner Erfahrung ziemlich miserabel. In bestimmten Fällen (z.B. VSTO-Addins) wird es sogar richtig hakelig. Am Ende bin ich dann fast immer bei "Suchen und Ersetzen" gelandet.

Generelle Empfehlungen zur Anzahl von Namensraumebenen sind mir nicht bekannt. Ich würde es nicht übertreiben. Vier oder fünf sollten in den meisten Fällen ausreichen, wobei innerhalb einer Anwendung die beiden obersten Ebenen normalerweise konstant bleiben, wenn man sich an die Empfehlung "Hersteller.Produkt.WeitereNamensräume" hält. Aufpassen solltest Du auf die (String-)Länge. Mir ist es schon passiert, dass ich an die max. Pfadlänge (ca. 240 Zeichen) unter Windows gestoßen bin: das Projekt lag irgendwo unter "C:\Dokumente und Einstellungen\userName", hatte ein paar geschachtelte Namespaces (und damit Ordner) mit langen Namen, und manche Dateien (Assemblys, *.datasource-Dateien) enthalten nochmal den kompletten Namespace im Dateinamen. Das summiert sich...
20.06.2012
Matthias Hlawatsch 13,2k 4 9
Zum Problem mit der Pfadlänge möchte ich anmerken, dass in .NET im Gegensatz zu Java die Namespaces nicht zwingend der Ordnerhierarchie entsprechen müssen. Somit könntest du theoretisch dein Pfadlängenproblem umgehen. Ich achte aber in der Regel auch darauf, dass sich meine Namespace-Hierarchie in der Ordnerstruktur widerspiegelt.
luedi 20.06.2012

Stelle deine .net-Frage jetzt!