•  09-06-2019
  •  | 
  •  

Frage

Mein Hintergrund ist hauptsächlich ein Java-Entwickler, aber in letzter Zeit arbeite ich auch etwas in .NET.Deshalb habe ich versucht, einige einfache Projekte zu Hause durchzuführen, um besser mit .NET arbeiten zu können.Ich konnte einen Großteil meiner Java-Erfahrung auf die Arbeit mit .NET (insbesondere C#) übertragen, aber das Einzige, was mich wirklich verwirrt hat, sind Namespaces.

Ich weiß, dass Namespaces Java-Paketen ähneln, aber soweit ich das beurteilen kann, besteht der Hauptunterschied darin, dass sie bei Java-Paketen tatsächliche Dateiordner verwenden, um die Trennung anzuzeigen, während dies in .NET nicht der Fall ist und sich alle Dateien in einem einzigen Ordner befinden und der Namespace wird einfach in jeder Klasse deklariert.

Ich finde das seltsam, weil ich Pakete immer als eine Möglichkeit gesehen habe, zusammengehörigen Code zu organisieren und zu gruppieren, um die Navigation und das Verständnis zu erleichtern.Da dies in .NET nicht auf diese Weise funktioniert, wirkt das Projekt im Laufe der Zeit überfüllter und nicht mehr so ​​einfach zu navigieren.

Vermisse ich hier etwas?Ich muss sein.Sollte ich die Dinge innerhalb der Lösung in separate Projekte aufteilen?Oder gibt es eine bessere Möglichkeit, die Klassen und Dateien innerhalb eines Projekts zu organisieren?

Bearbeiten:Wie Blair betonte, ist dies im Wesentlichen die gleiche Frage, die gestellt wird Hier.

War es hilfreich?

Lösung

Ich kann nicht behaupten, dass es eine bewährte Methode, aber ich sehe oft Dateien in einer Verzeichnishierarchie organisiert, die den Namensraum widerspiegelt. Wenn es Ihr mentales Modell von dem Code besser paßt, dann so tun - ich kann nicht jeden Schaden denken. Nur weil das .NET Modell Namespaces, Projekte erzwingt nicht die Beziehungen zwischen und Verzeichnisstruktur bedeutet nicht, dass Sie nicht solche Beziehungen haben können, wenn Sie wollen.

würde ich den Code in mehreren Projekten ein wenig misstrauisch auseinanderzubrechen, als Sie benötigen, da diese Compilation verlangsamen kann und ein wenig Aufwand hinzufügen, wenn Sie mehrere Baugruppen zu verwalten haben.

EDIT: Beachten Sie, dass diese Frage fast ein Duplikat ist die Ordner sollten den Namespace in einer Lösung überein?

Andere Tipps

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

Wenn in Visual Studio arbeiten, IDE neigt neuen Namensraum einzuführen, wenn Sie neue Ordner hinzufügen Baum zu projizieren.

Hier ist ein nützlicher Link von MSDN:

Namespace Richtlinien zur Benennung

  

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

Natürlich können Sie Namespaces in der Art und Weise können Sie besser geeignet finden. Allerdings, wenn Sie Ihren Code gehen zu teilen, würde ich empfehlen, mit dem anerkannten Standards zu gehen.

Bearbeiten :

ich jeden .net Entwickler empfehlen, eine Kopie von Rahmen Design-Richtlinien zu erhalten Dieses Buch wird Ihnen helfen, zu verstehen, wie und warum .NET entwickelt wurde.

A VS Lösung enthält in der Regel ein oder mehrere Projekte. Thse Projekte haben Standardnamensraum (in der Regel der Namespace ist nur der Name des Projekts). Normalerweise werden genannt werden, wenn Sie einen Ordner innerhalb des Projektes, alle Klassen in ihm wie folgt hinzufügen:

  
    

DefaultNamespace.FolderName.ClassName

  

Natürlich können Sie den Standard-Namespace des Projekts ändern, und lassen Sie Ihre Klassen in benennen welcher Weise auch immer Sie wollen.

Was wann / wie Sachen in Projekte zu brechen, das ist eine Sache der Erfahrung und / oder Vorzugs. Sie sollten jedoch unbedingt Sachen in Projekte in einer Lösung durchbrechen, um Ihr Projekt organisiert. Wenn die Verwaltung zu viele Baugruppen umständlich wird (als Blair vorgeschlagen), können Sie immer ILMerge Ihre Baugruppen in einer einzigen Baugruppe. Was ist toll an ILMerge ist, dass obwohl Sie mit nur einer Versammlung am Ende, alle Klassen behalten ihre ursprünglichen voll qualifizierten Namen.

Es ist auch wichtig zu bedenken, dass eine VS-Lösung keinen Einfluss auf Code hat - dh. sie werden nicht gebaut. VS-Lösungen sind nichts anderes als eine Möglichkeit, Gruppenprojekte; es sind die Projekte, die in DLLs sind eingebaut und eingeschaltet.

Schließlich sei VS die Sie „virtuelle“ Ordner überall in der Lösung hinzuzufügen. Diese Ordner ordnen nicht in einen Ordner im Dateisystem und werden nur als ein weiteres Mittel verwendet, um Sie helfen, Ihre Projekte und andere Artefakte innerhalb der Lösung zu organisieren.

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

Warum ist das wichtig? Denken Sie über .NET 2.0, 3.0 und 3.5. .NET 3.0 ist im Grunde .NET 2.0 mit einigen zusätzlichen Baugruppen und 3.5 fügt ein paar mehr Baugruppen. So zum Beispiel, die eine Web-Kontrolle und soll .NET 3.5 fügt die DataPager Kontrolle, in System.Web.UI.WebControls gruppiert werden. Wenn Namespaces und physische Standorte identisch waren, konnte es nicht sein, weil es in einer anderen Anordnung ist.

So Namespaces als unabhängige logische Einheiten, die bedeutet, dass Sie Mitglieder von mehreren verschiedenen Baugruppen aufweisen können, die alle logisch zusammengefasst werden, weil sie in Verbindung miteinander verwendet werden, gemeint sind.

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

Tatsächlich ist die .NET-Umgebung können Sie Ihren Code am IDE / Dateisystem wie Spaghetti gegen eine Wand werfen.

Das bedeutet nicht, dass bedeutet dieser Ansatz vernünftig ist, aber. Seine im Allgemeinen eine gute Idee, mit dem project.foldername.Class Ansatz zu haften, die zuvor erwähnt wurden. Es ist auch eine wirklich gute Idee, alle Klassen von einem Namespace in die gleiche Klasse zu halten.

In Java können Sie verrückt Dinge tun, wie dies auch alle von der „Flexibilität“ bekommen, die Sie wollen, aber die Werkzeuge sind in der Regel dringend abraten. Ehrlich gesagt, eine der verwirrendsten Dinge für mich in der Welt Net eingeführt war, wie schlampig / inkonsistent dies dank der relativ schlechte Führung sein kann. Sein einfachen Dinge zu organisieren sanely mit einem wenig Gedanken, though. :)

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

.net-Namespaces sind rein deklarativen Umfang verwalten und nichts mit Dateien, Projekten und deren Standorte zu tun.

Es ist sehr einfach, alles in einem bestimmten Namespace deklariert ist zugänglich, wenn Sie umfassen ein ‚mit‘ zu diesem Namensraum.

sehr einfach.

die Wahl des Namens oder nicht und ob / wie viele ‚‘ seperators Sie verwenden, ist ganz Ihnen überlassen.

VS standardmäßig das Hinzufügen .foldernames zu Ihrem Namensraum nur um zu versuchen und hilfreich sein.

Dieser Artikel beschreibt, Namespaces ganz gut: http://www.blackwasp.co.uk/Namespaces.aspx

Es hat auch ein Beispiel Konvention gegen Ende zu nennen, obwohl Ihre Namenskonvention Ihr Anruf! ;)

, die besagten, die meisten Orte, die ich gearbeitet habe an und Leute, die ich habe mit Start mit Firmennamen gearbeitet, die sinnvoll ist, da es typenames für das Unternehmen deutlich, (getrennt von anderen, Bibliotheken, Lieferanten, Open-Source-projcts macht usw. )

Sie können für jeden Namespace-Ordner zu Ihrer Lösung hinzuzufügen. Es ist zwar noch zu einem einzigen ausführbaren kompilieren wird, ist es Ihre Source-Dateien und gibt organisiert (was ich denke, ist), um den gewünschten Effekt?

Ich füge normalerweise einen Ordner für jeden Namespace in meinem Projekt, und nisten sie nach der gleichen Hierarchie (MyApp.View.Dialogs zum Beispiel)

Namensräume sind rein semantisch. Während sie in der Regel eine Ordnerstruktur spiegeln, zumindest wenn Visual Studio IDE verwenden, brauchen sie nicht zu.

Sie können den gleichen Namensraum in mehreren Bibliotheken referenziert haben, hässlich, aber wahr.

Ich habe immer Quelldatei Organisation und die Zuweisung Bezeichner Klassen und Objekte als zwei getrennte Probleme. Ich neige dazu, verwandte Klassen in Gruppen zu halten, aber nicht sollte jede Gruppe ein Namespace sein. Namensräume vorhanden ist (mehr oder weniger), um das Problem der Namenskonflikte-in Flat-Namespace-Sprachen wie C zu lösen, kann man nicht zu Fuß zwei Füße ohne über Identifikatoren wie mycompany_getcurrentdate oder MYCGetCurrentDate Auslösung, da das Risiko eines Konflikt mit einer anderen Funktion in einem Drittanbieter (oder System) Bibliothek ist, dass viel kleiner. Wenn Sie ein Paket oder ein Namespace für jede logische Trennung erstellt, würden Sie bekommen (Java-Beispiel) Klassennamen wie java.lang.primitivewrapper.numeric.Integer, die ziemlich viel des Guten ist.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top