.NET-Namespaces

Question

Mein Hintergrund ist in erster Linie als Java-Entwickler, aber in letzter Zeit habe ich etwas Arbeit in .NET. Also habe ich versucht, ein paar einfache Projekte zu Hause zu machen, um besser mit .NET arbeiten zu können. Ich war in der Lage, einen Großteil meiner Java-Erfahrung in die Arbeit mit .NET (speziell C#) zu übertragen, aber das einzige, was mich wirklich verwirrt hat, sind Namespaces.

Ich weiß Namespaces sind ähnlich wie Java-Pakete, aber von was ich sagen kann, ist der Hauptunterschied, dass mit Java-Paketen tatsächliche Dateiordner verwenden, um die Trennung anzuzeigen, während in .NET nicht und alle Dateien befinden in einem einzigen Ordner und der Namespace wird einfach in jeder Klasse deklariert.

Ich finde das merkwürdig, weil ich Pakete immer als eine Möglichkeit sah, damit verbundenen Code zu organisieren und zu gruppieren, was es einfacher macht, zu navigieren und zu verstehen. Da in .NET auf Überstunden gearbeitet wird, wirkt das Projekt überladen und nicht so einfach zu navigieren.

Fehle ich hier etwas? Ich muss sein. Soll ich Dinge in einzelne Projekte innerhalb der Lösung einteilen? Oder gibt es eine bessere Möglichkeit, die Klassen und Dateien in einem Projekt zu organisieren?

Edit: Wie Blair darauf hingewiesen, ist dies ziemlich die gleiche Frage here.

Answer 1

Ich kann nicht behaupten, dass es eine Best Practice ist, aber ich sehe oft Dateien in einer Verzeichnishierarchie organisiert, die den Namespace spiegelt. Wenn es zu Ihrem mentalen Modell des Codes passt, dann tun Sie es - ich kann mir keinen Schaden vorstellen. Nur weil das .NET-Modell Beziehungen zwischen Namespaces, Projekten und Verzeichnisstrukturen nicht erzwingt, bedeutet das nicht, dass Sie solche Beziehungen nicht haben können, wenn Sie möchten.

Ich wäre ein wenig misstrauisch, den Code in mehr Projekte aufzuteilen, als Sie benötigen, da dies die Kompilierung verlangsamen und ein wenig Overhead hinzufügen kann, wenn Sie mehrere Assemblies verwalten müssen.

EDIT: Beachten Sie, dass diese Frage ist fast ein Duplikat should the folders in a solution match the namespace?

Answer 2

Sie Ordner, um Ihre Lösung für jeden Namensraum hinzufügen können. Während es immer noch zu einer einzigen ausführbaren Datei kompiliert wird, organisiert es Ihre Quelldateien und gibt (was ich denke) den gewünschten Effekt?

I fügen typischerweise einen Ordner für jeden Namensraum in meinem Projekt, und Nest sie nach der gleichen Hierarchie (MyApp.View.Dialogs zum Beispiel)

Answer 3

A VS Lösung enthält in der Regel ein oder mehr Projekte. Diese Projekte haben Standard-Namespaces (normalerweise ist der Namespace nur der Name des Projekts). Normalerweise wird wie folgt, wenn Sie einen Ordner innerhalb des Projekts, alle Klassen in sie fügen dem Namen:

DefaultNamespace.FolderName.ClassName

Natürlich können Sie das ändern Standard-Namespace des Projekts, und lassen Sie Ihre Klassen auf die von Ihnen gewünschte Weise benennen.

Bis wann/wie man Sachen in Projekte zu brechen, das ist eine Frage der Erfahrung und/oder Präferenz. Sie sollten jedoch innerhalb einer Lösung Dinge in Projekte aufteilen, um Ihr Projekt zu organisieren. Wenn die Verwaltung zu vieler Baugruppen mühsam wird (wie Blair vorgeschlagen hat), können Sie Ihre Baugruppen immer in eine einzelne Baugruppe zerlegen.Was ist toll an ILMerge ist, dass, obwohl Sie mit nur einer Assembly enden, alle Ihre Klassen ihre ursprünglichen voll qualifizierten Namen behalten.

Es ist auch wichtig, daran zu denken, dass eine VS-Lösung keinen Einfluss auf den Code hat - dh. sie werden nicht gebaut. VS Solutions sind nichts anderes als eine Möglichkeit, Projekte zu gruppieren. Es sind die Projekte, die erstellt und in DLLs umgewandelt werden.

Schließlich VS können Sie "virtuelle" Ordner überall in der Lösung hinzufügen. Diese Ordner werden keinem Ordner im Dateisystem zugeordnet und dienen nur als weitere Möglichkeit, Ihre Projekte und andere Artefakte innerhalb der Lösung zu organisieren.

Answer 4

Ja, in .NET-Namespace hängt nicht von Dateisystem oder etwas anderes ab. Es ist meiner Meinung nach ein großer Vorteil. Zum Beispiel können Sie Ihren Code auf verschiedene Baugruppen aufteilen, was eine flexible Verteilung ermöglicht.

Bei der Arbeit in Visual Studio neigt die IDE dazu, einen neuen Namespace einzuführen, wenn Sie einen neuen Ordner zur Projektnavigation hinzufügen. Hier

ist eine nützliche Verbindung von MSDN:

Namespace Naming Guidelines

Die allgemeine Regel für die Benennung von Namespaces ist den Firmennamen von die Technologie Namen und optional die Funktion und Design gefolgt zu verwenden, wie folgt.
CompanyName.TechnologyName [.Feature.] [Design]

Natürlich können Sie Namespaces in der Art und Weise Sie besser geeignet finden können. Wenn Sie jedoch Ihren Code teilen möchten, würde ich empfehlen, mit akzeptierten Standards zu gehen.

EDIT:

ich jeden .net Entwickler empfehlen, eine Kopie von Framework design guidelines Dieses Buch zu bekommen, helfen Ihnen wie und warum .NET ausgelegt ist, zu verstehen.

Answer 5

Namensräume sind rein semantisch. Während sie normalerweise eine Ordnerstruktur widerspiegeln, müssen sie dies zumindest bei Verwendung der Visual Studio-IDE nicht tun.

Sie können denselben Namespace in mehreren Bibliotheken referenzieren, hässlich aber wahr.

Answer 6

In der Tat, die. NET-Umgebung ermöglicht es Ihnen, Ihren Code im IDE/Dateisystem wie Spaghetti gegen eine Wand zu werfen.

Das bedeutet nicht, dass dieser Ansatz vernünftig ist, jedoch. Es ist in der Regel eine gute Idee, bei der project.foldername.Class-Methode zu bleiben, die bereits erwähnt wurde. Es ist auch eine wirklich gute Idee, alle Klassen von einem Namespace in derselben Klasse zu halten.

In Java können Sie auch solche kniffligen Dinge tun, indem Sie all die "Flexibilität" bekommen, die Sie wollen, aber die Werkzeuge tendieren dazu, davon stark abzuraten. Ehrlich gesagt war eines der verwirrendsten Dinge für mich, als ich in die .Net-Welt eingeführt wurde, wie schlampig/inkonsistent dies sein kann, dank der relativ schlechten Führung. Es ist leicht, die Dinge mit ein wenig Nachdenken vernünftig zu organisieren.:)

Answer 7

Ich habe immer Quelldateiorganisation und Zuordnung von Bezeichnern zu Klassen und Objekten als zwei separate Probleme betrachtet. Ich neige dazu, verwandte Klassen in Gruppen zu halten, aber nicht jede Gruppe sollte ein Namensraum sein. Namespaces existieren (mehr oder weniger), um das Problem von Namenskonflikten zu lösen - in Sprachen mit flachen Namespaces wie C können Sie keine zwei Fuß laufen ohne über Identifikatoren wie mycompany_getcurrentdate oder MYCGetCurrentDate zu stolpern, weil das Risiko eines Konflikts mit einer anderen Funktion in einem Third-Party (oder System) -Bibliothek ist so viel kleiner. Wenn Sie für jede logische Trennung ein Paket oder einen Namespace erstellen, erhalten Sie (Java-Beispiel) Klassennamen wie java.lang.primitivewrapper.numeric.Integer, was ziemlich übertrieben ist.

Answer 8

Namespaces sind eine logische Gruppierung, während Projekte eine physische Gruppierung sind.

Warum ist das wichtig? Denken Sie an .NET 2.0, 3.0 und 3.5. .NET 3.0 ist im Wesentlichen .NET 2.0 mit einigen zusätzlichen Assemblys und 3.5 fügt einige weitere Assemblys hinzu. So fügt zum Beispiel .NET 3.5 das Steuerelement DataPager hinzu, das ein Web-Steuerelement ist und in gruppiert werden sollte. Wenn Namespaces und physische Speicherorte identisch sind, kann dies nicht der Fall sein, da sie sich in einer anderen Assembly befinden.

Wenn Namespaces als unabhängige logische Entitäten definiert sind, bedeutet dies, dass Sie Mitglieder mehrerer verschiedener Assemblys haben können, die alle logisch zusammen gruppiert sind, da sie für die Verwendung in Verbindung miteinander gedacht sind.

(Auch gibt es nichts falsch mit Ihren physischen und logischen Layouts ziemlich ähnlich sind.)

Answer 9

der Unterschied ist, dass .net-Namespaces hat nicht viel mit Java-Paketen zu tun.

.net-Namespaces dienen ausschließlich zur Verwaltung des deklarativen Bereichs und haben nichts mit Dateien, Projekten oder ihren Speicherorten zu tun.

es ist sehr einfach, alles, was in einem bestimmten Namespace deklariert ist, ist zugänglich, wenn Sie ein 'using' zu diesem Namespace enthalten.

sehr einfach.

die Wahl des Namens und ob oder wie viele '.' Trenner, die Sie verwenden, liegt ganz bei Ihnen.

Standardmäßig fügt VS die Namen von .foldernamen hinzu, nur um zu versuchen, hilfreich zu sein.

dieser Artikel erklärt Namespaces ganz gut: http://www.blackwasp.co.uk/Namespaces.aspx

Es ist auch ein Beispiel Namenskonvention gegen Ende hat, obwohl Ihre Namenskonvention Ihren Anruf! ;) Das sagte, die meisten Orte, an denen ich gearbeitet habe und Leute, mit denen ich gearbeitet habe, beginnen mit dem Firmennamen, der sinnvoll ist, da er typename für dieses Unternehmen unterscheidet (getrennt von anderen, Bibliotheken, Anbietern, Opensource) Projekte usw.)