.NET-Namespaces

Ich kann nicht behaupten, dass dies eine bewährte Methode ist, aber ich sehe oft Dateien in einer Verzeichnishierarchie, die den Namespace widerspiegelt. 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 der Verzeichnisstruktur nicht erzwingt, bedeutet das nicht, dass Sie solche Beziehungen nicht haben können, wenn Sie möchten.

Ich würde ein wenig mürrisch sein, den Code in mehr Projekte aufzuteilen, als Sie brauchen, 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 fast ein Duplikat von ist Sollen die Ordner in einer Lösung mit dem Namespace übereinstimmen?

Ja, im .NET Namespace hängt nicht vom Dateisystem oder irgendetwas anderem 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.

Wenn Sie in Visual Studio arbeiten, neigt IDE dazu, einen neuen Namespace einzuführen, wenn Sie einen neuen Ordner zur Projektnavigation hinzufügen.

Hier ist ein nützlicher Link von MSDN:

Namensraum-Namensrichtlinien

  

Die allgemeine Regel für das Benennen von Namespaces   ist der Firmenname gefolgt von   der Technologie Name und optional der   Feature und Design wie folgt.
CompanyName.TechnologyName [.Feature] [. Design]

Natürlich können Sie Namespaces so verwenden, wie Sie es besser finden. Wenn Sie jedoch Ihren Code teilen möchten, würde ich empfehlen, mit akzeptierten Standards zu gehen.

BEARBEITEN :

Ich empfehle jedem .net-Entwickler dringend, eine Kopie von Framework-Design-Richtlinien zu erhalten. Dieses Buch wird Ihnen helfen zu verstehen, warum und warum .NET entworfen wurde.

Eine VS-Lösung enthält normalerweise ein oder mehrere Projekte. Diese Projekte haben Standard-Namespaces (normalerweise ist der Namespace nur der Name des Projekts). Wenn Sie einen Ordner innerhalb des Projekts hinzufügen, werden normalerweise alle darin enthaltenen Klassen wie folgt benannt:

  

    

DefaultNamespace.FolderName.ClassName

  

Natürlich können Sie den Standard-Namespace des Projekts ändern und Ihre Klassen so benennen, wie Sie möchten.

Was wann / wie man Sachen in Projekte einteilt, ist Erfahrung und / oder Vorliebe. Sie sollten jedoch innerhalb einer Lösung Dinge in Projekte aufteilen, um Ihr Projekt zu organisieren. Wenn das Verwalten zu vieler Assemblies mühsam ist (wie Blair vorgeschlagen hat), können Sie Ihre Assemblys immer in eine einzelne Assembly ILMerge integrieren . 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 zu bedenken, 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 können Sie VS überall in der Lösung "virtuelle" Ordner hinzufügen. Diese Ordner werden keinem Ordner im Dateisystem zugeordnet und dienen lediglich als weitere Möglichkeit, Ihre Projekte und andere Artefakte in der Lösung zu organisieren.

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 beispielsweise .NET 3.5 das Steuerelement DataPager hinzu, das ein Web-Steuerelement ist und in System.Web.UI.WebControls gruppiert werden sollte. Wenn Namespaces und physische Speicherorte identisch sind, kann dies nicht der Fall sein, da sie sich in einer anderen Assembly befinden.

Namespaces als unabhängige logische Entitäten zu haben bedeutet also, dass Sie Mitglieder mehrerer verschiedener Assemblys haben können, die alle logisch zusammen gruppiert sind, da sie dazu bestimmt sind, in Verbindung miteinander verwendet zu werden.

(Es ist auch nichts falsch daran, dass Ihre physischen und logischen Layouts ziemlich ähnlich sind.)

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

Das bedeutet nicht, dass dieser Ansatz vernünftig ist. 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 andere Dinge wie diese "Flexibilität" erreichen, aber die Tools tendieren dazu, davon 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. :)

Der Unterschied ist, dass .net Namespaces nicht viel mit Java-Paketen zu tun haben.

.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 Sie fügen dem Namensbereich eine 'Verwendung' hinzu.

sehr einfach.

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

Standardmäßig fügt VS Ihren Namespaces nur .foldernames hinzu, um zu versuchen, hilfreich zu sein.

Dieser Artikel erklärt Namespaces ziemlich gut: Ссылка

Es gibt auch eine Beispiel-Namenskonvention gegen Ende, obwohl Ihre Namenskonvention Ihr Aufruf ist! ;)

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 Typnamen für dieses Unternehmen unterscheidet (getrennt von anderen, Bibliotheken, Anbietern, Open Source-Projekten usw.). )

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

Ich füge normalerweise einen Ordner für jeden Namespace in meinem Projekt hinzu und verschachtele sie nach derselben Hierarchie (zB MyApp.View.Dialogs)

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.

Ich habe immer die Organisation von Quelldateien und die 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 flachen Namespace-Sprachen wie C können Sie nicht zwei Fuß laufen, ohne über Identifier wie mycompany_getcurrentdate oder MYCGetCurrentDate zu stolpern, weil das Risiko eines Konflikts mit Eine andere Funktion in einer Bibliothek eines Drittanbieters (oder eines Systems) ist viel kleiner. Wenn Sie für jede logische Trennung ein Paket oder einen Namespace erstellt haben, würden Sie (Java-Beispiel) Klassennamen wie java.lang.primitivewrapper.numeric.Integer erhalten, was ziemlich übertrieben ist.