it-swarm.com.de

Sollte ich aufhören, die Standard-Namensraumkonvention von Visual Studio zu bekämpfen?

Ich arbeite an einem MVVM-Projekt, also habe ich in meinem Projekt Ordner wie Models, ViewModels, Windows usw. Wenn Sie eine neue Klasse erstellen, fügt Visual Studio automatisch den Ordnernamen der Namensraumbezeichnung hinzu, anstatt nur das Projekt zu behalten. Level-Namespace. Wenn Sie dem ViewModels-Ordner eine neue Klasse hinzufügen, würde dies zu dem Namespace MyProject.ViewModels statt nur MyProject führen.

Als ich das zum ersten Mal sah, ärgerte es mich. Meine Klassennamen sind ziemlich klar und enthalten manchmal sogar den Namen des Ordners (z. B. ContactViewModel). Ich fand schnell, dass ich den Ordnernamen in den Namespaces manuell entfernte. Ich habe sogar einmal versucht, eine benutzerdefinierte Klassenvorlage zu erstellen (siehe diese Frage ), aber ich konnte das nicht zum Laufen bringen, also fuhr ich fort, es manuell zu tun.

Ich frage mich jedoch, ob diese Konvention aus einem guten Grund existiert, den ich einfach nicht sehe. Ich könnte es als nützlich erachten, wenn Sie aus irgendeinem Grund viele Sätze identischer Klassennamen in Ordnern organisiert hatten, aber dies scheint kein besonders übliches Szenario zu sein.

Fragen:

  • Warum ist es üblich, dass Namensraumnamen die Ordnerstruktur widerspiegeln?
  • Halten Sie sich an diese Konvention? Warum?
63
devuxer

Genau wie du - ich habe das am längsten gekämpft. Dann überlegte ich mir, warum ich Ordner erstellt habe. Ich fing an, Ordner zu erstellen, um Namespaces und Pakete anstelle von beliebigen Buckets darzustellen. 

In einem MVVM-Projekt kann es beispielsweise hilfreich sein, Ansichten und Ansichtsmodelle in einem separaten Namespace abzulegen. MVC verfügt über einen separaten Namespace für Modelle, Controller und Ansichten. Es ist auch vorteilhaft, Klassen nach ihrem Merkmal zu gruppieren. 

Plötzlich fühlt sich das Projekt organisierter an. Für andere Entwickler ist es einfacher zu finden, wo Features implementiert sind.

Wenn Sie Ihre Namensraumpraktiken standardisieren, haben alle Ihre Projekte die gleiche vorhersagbare Struktur, was für die Wartung ein großer Gewinn ist.

46
Jordan Parmer

Wenn Sie einen soliden Rat wünschen, würde ich den Kauf von Framework Design Guidelines: Konventionen, Idiomen und Mustern für wiederverwendbare .NET-Bibliotheken empfehlen, der Ihnen alles bietet, was Sie vom eigentlichen Framework-Designteam wissen müssen.

... Das Ziel bei der Benennung von Namespaces besteht darin, dem Programmierer ausreichend Klarheit zu verschaffen, indem er das Framework verwendet, um sofort zu wissen, wie der Inhalt des Namespaces wahrscheinlich ist ...

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Und wichtig

Verwenden Sie nicht denselben Namen für einen Namespace und einen Typ in diesem Namespace

Die Fragmentierung aller 1/2-Typen in Namespaces würde die erste Anforderung nicht erfüllen, da Sie über einen Sumpf von Namespaces verfügen, die qualifiziert oder verwendet werden müssten, wenn Sie den Anweisungen von Visual Studio folgen. Zum Beispiel

Ader - Domäne - Benutzer - Berechtigungen - Konten

Würdest du schaffen?

  • MyCompany.Core.Domain.Users
  • MyCompany.Core.Domain.Permissions
  • MyCompany.Core.Domain.Accounts

oder nur

  • MyCompany.Core.Domain

Für Visual Studio wäre dies der erste. Wenn Sie die Benennung von Dateien/Ordnern in Kleinbuchstaben verwenden, müssen Sie die Klasse jedes Mal umbenennen und außerdem einen großen Namensraum anlegen.

Das meiste davon ist vernünftig und hängt wirklich davon ab, wie Sie erwarten würden, dass die Namespaces organisiert wären, wenn you ein Benutzer Ihrer eigenen API oder Ihres eigenen Frameworks wäre.

17
Chris S

ich war auch darüber verärgert, aber die Arbeit mit und das Umgestalten von Projekten mit großen Codebasis hat mich schnell etwas anderes gelehrt. Nachdem ich das Konzept angenommen habe, denke ich, dass es eine sehr gute Möglichkeit ist, Ihren Code sowohl physisch als auch logisch zu strukturieren. Wenn Sie ein großes Projekt haben und die Namespaces nicht mit den Ordnern übereinstimmen, wird es schwierig, Dateien schnell zu finden. Es ist auch viel schwieriger, sich daran zu erinnern, wo die Dinge sind ...

Wenn ReSharper es empfiehlt, ist es wahrscheinlich eine gute Idee. Z.B. R # beschwert sich, wenn der Namespace Ihrer Klasse nicht mit dem Ordnernamen übereinstimmt.

10
Paul Sasik

Sie können die Konventionen nicht befolgen, indem Sie die Datei im Stammordner des Projekts erstellen und dann in den endgültigen Unterordner verschieben.

Jedenfalls ist es eine Konvention, die ich eigentlich mag. Wenn ich Typen in Ordner aufspalte, haben diese Typen wahrscheinlich eine Art konzeptioneller Gruppierung, die sich auf den Ordner bezieht. Daher ist es sinnvoll, ihre Namespaces sind auch ähnlich. Java verfolgt diesen Ansatz und erzwingt ihn mit seinem Paketsystem. Der größte Unterschied ist, dass VS es Ihnen nur "vorschlägt", da weder die Sprache noch die CLR es erzwingen.

5
Rui Craveiro

Dateisystemordner und Namespaces repräsentieren beide eine Hierarchie. Es scheint mir völlig natürlich zu sein, die beiden zusammenzubringen. Ich gehe noch einen Schritt weiter und verwende eine 1: 1-Beziehung zwischen Dateien und Klassen. Ich mache das sogar, wenn ich in anderen Sprachen wie C++ programmiere.

Nun, da Sie die Beziehung zwischen diesen beiden Hierarchien in Frage stellen, frage ich mich ernsthaft, was Sie durch die Dateisystemhierarchie darstellen möchten.

5
Malte Clasen

Ich stimme mit allen anderen überein, dass eine physische Struktur, die der logischen Struktur entspricht, hilfreich ist. Ich muss jedoch sagen, dass ich auch mit der automatischen Benennung von Visual Studio zu kämpfen habe. Es gibt ein halbes Dutzend Gründe, warum ich Klassen umbenennen muss:

  • Ich verwende einen Stammordner "src", um meinen Code visuell von eingebetteten Ressourcen zu trennen
  • Ich möchte unterschiedliche Kapitalisierung
  • Ich organisiere meinen Code in Unterordnern für die Organisation innerhalb eines Namespaces
  • Ich trenne gerne Schnittstellen von Implementierungen und Basisklassen
  • Ich fühle mich danach

Aus diesen Gründen habe ich mich damit abgefunden, diese für jede von mir geschaffene Klasse anpassen zu müssen. Meine Strategie zur Vermeidung des Problems besteht darin, eine Datei mit der von mir gewünschten Namespace-Deklaration zu kopieren und den Inhalt sofort zu löschen.

4
Hounshell

Vor der Einführung von Namespaces in C++ befanden sich alle C-Typen im globalen Namespace. Namensräume wurden erstellt, um Typen in logische Container zu unterteilen, sodass klar war, auf welchen Typ verwiesen wird. Dies gilt auch für C #. 

Baugruppen sind eine Bereitstellungsentscheidung. Wenn Sie sich das .Net-Framework anschauen, enthält eine bestimmte Assembly mehrere verschiedene Namespaces.

Ordner dienen zum Organisieren von Dateien auf der Festplatte. 

Die drei haben nichts miteinander zu tun, es ist jedoch oft zweckmäßig, dass der Name der Assembly, der Namespace und der Ordner identisch sind. Beachten Sie, dass Java Ordner und Namespaces auf dieselbe Weise reduziert (die Freiheit des Entwicklers, Dateien und Namespaces zu organisieren, eingeschränkt wird).

Häufig entscheiden wir uns dafür, Dateien in einem Projekt in mehreren Ordnern zu organisieren, da es für mich oder mein Team einfacher ist, durch die Dateien zu navigieren. Normalerweise hat diese Dateiorganisation nichts mit dem von uns verwendeten Namespace-Design zu tun. Ich wünschte, das VS-Team würde nicht standardmäßig den Namespace mit dem Ordnernamen identisch machen oder zumindest die Option zurückgeben, dass dies nicht der Standardwert ist. 

Nicht leiden, ändern Sie entweder die Vorlage für neue Klassen oder korrigieren Sie den Namespace, nachdem die neue Datei erstellt wurde.

3
Franklin Wise

Ich denke, dass es durchaus Gründe gibt, unterschiedliche Strukturen für Namespaces und Projektordner zu haben. Wenn Sie eine Bibliothek entwickeln, sollte die Namespace-Struktur in erster Linie den Nutzern Ihrer API dienen: Sie sollte logisch und leicht verständlich sein. Auf der anderen Seite sollte die Ordnerstruktur in erster Linie vorhanden sein, um Ihnen das Leben zu erleichtern, dem API-Designer . Einige Ziele sind in der Tat sehr ähnlich, so dass auch die Struktur logisch sein sollte. Es kann jedoch auch andere geben, z. dass Sie schnell verwandte Dateien für die Werkzeugauswahl auswählen können oder einfach navigieren können. Ich selbst neige zum Beispiel dazu, neue Ordner zu erstellen, wenn ein bestimmter Schwellenwert für die Datei erreicht wird. Andernfalls dauert es einfach zu lange, um die gesuchte Datei zu finden. Die Präferenz des Designers zu respektieren kann jedoch auch strikt dem Namespace folgen - wenn dies seine Präferenz ist.

Insgesamt macht es in vielen Fällen Sinn, dass beide übereinstimmen, aber ich denke, dass es gültige Fälle gibt, von denen abgewichen werden kann.

In der Vergangenheit war es für mich hilfreich, eine Datei (z. B. WPF UserControl) an einer Stelle zu erstellen, um den Namespace richtig zu machen, und ihn dann in den "rechten" Ordner verschieben.

2
micTronic

Ich fühle auch den Schmerz mit diesem "standardmäßig" Verhalten in Visual Studio. 

Wenn Sie Ihre LinqToSql .dbml-Dateien in ihrem eigenen Verzeichnis ablegen, versucht Visual Studio auch, eine Übereinstimmung zwischen Namespace/Verzeichnis festzulegen. Wenn ich den .dbml bearbeite, muss ich Folgendes beachten:

  • Öffnen Sie die .dbml.designer.cs-Datei
  • entfernen Sie den Verzeichnis-/Ordnernamen aus der namespace-Deklaration

Es gibt jedoch eine Möglichkeit, stoppen Sie dieses Verhalten . Dazu gehört das Erstellen einer benutzerdefinierten Klassenvorlage.

2
p.campbell

Obwohl ich damit einverstanden bin, dass das Anpassen der Namensraumhierarchie an die Ordnerhierarchie praktisch und eine gute Idee ist, denke ich, dass die Tatsache, dass Visual Studio das Abschalten dieser Funktion nicht zu unterstützen scheint, ekelhaft ist. In Visual Studio gibt es viele Anwendungen, und es gibt zahlreiche Codierungsstile und Möglichkeiten, die Quelldateiordner perfekt zu strukturieren. 

Angenommen, es gibt Tausende von Dateien, die in einen Namespace gehören, aber der Programmierer möchte sie nur in Ordnern gruppieren, um die Navigation der Hierarchie zu erleichtern. Ist das wirklich eine so schlechte Idee? Ist das wirklich so unwartbar, dass es von der IDE verboten werden sollte?

Angenommen, ich verwende Visual Studio, um mit Unity zu arbeiten. Jetzt befinden sich alle meine Skripts im Namespace "Assets.Scripts". Es gibt nicht nur einen nutzlosen Assets-Namespace, der jetzt keine Skripts enthält, sondern "Assets.Scripts" hat keine Bedeutung - er beschreibt nicht, zu welchem ​​Projekt oder zu welchem ​​Teil des Projekts die Quelldatei gehört. Nutzlos. 

0
Sava B.