Namenskonventionen für Teilklassendateien

Ich generiere den Großteil meines ASP.NET MVC-Gerüstcodes. Alle generierten Dateien sind Teilklassen, die Standard-Namenskonventionen verwenden. Beispielsweise heißt meine Mitarbeiter-Controller-Datei EmployeeController.cs. Wenn ich den EmployeeController mit benutzerdefinierter, nicht generierter Logik erweitern möchte, erstelle ich eine zweite Teilklassendatei mit dem Namen EmployeeControllerCustom.cs. Ich trenne die benutzerdefinierte und generierte Logik in zwei verschiedene Dateien, damit meine benutzerdefinierten Änderungen beim nächsten Generieren des EmployeeController nicht überschrieben werden. Das Hinzufügen des Suffixes "Benutzerdefiniert" zum Dateinamen erscheint mir vernünftig, aber gibt es eine etabliertere Namenskonvention für Teilklassendateien, die ich befolgen sollte?

c# naming-conventions code-generation partial-classes

— Ben Griswold
quelle

Antworten:

151

Ich benutze .zum Beispiel Trennung EmployeeController.SomeSpecialBehaviour.cs. Ich verknüpfe es auch über "abhängiges Upon" oder was auch immer es im csproj ist, in den Projektbaum, damit es ordentlich unter der Datei (im Lösungs-Explorer) verschachtelt ist. Sie müssen dies jedoch von Hand (bearbeiten Sie das csproj) oder mit einem Add-In tun. beispielsweise:

<Compile Include="Subfolder/Program.cs" />
<Compile Include="Subfolder/Program.Foo.cs">
  <DependentUpon>Program.cs</DependentUpon> <!-- Note that I do not reference the subfolder here -->
</Compile>

erscheint als:

Unterordner
- Program.cs
  - Program.Foo.cs

— Marc Gravell
quelle

Der DependentUpon-Vorschlag ist wirklich cool und funktioniert hervorragend. Vielen Dank für die Notiz. Wenn ich richtig lese, verwenden Sie nicht einfach ein Standardsuffix wie "Benutzerdefiniert". Ihr Suffix drückt immer die Absicht der Funktionalität der Teilklassendatei aus. Gibt es auch einen Grund, warum Sie die verwenden. Trennung gegen Gehäuse? Tut das. mehr als eine verbesserte Lesbarkeit bieten? Vielen Dank.

— Ben Griswold

Richtig - Der Dateiname gibt die Absicht des Codes in diesem Abschnitt an . Wenn ich also eine exotische Schnittstelle implementiere (und den Code getrennt halte), könnte dies der Fall sein SomeType.ICustomTypeDescriptor.cs. Die .(IMO) trennt die beiden Dinge: den tatsächlichen Typ ( SomeType) und die Absicht ICustomTypeDescriptor- beide sind bereits vollständig ummantelt; SomeForm.Designer.csAußerdem

— passt

Perfekt. Vielen Dank für den zusätzlichen Einblick. Wenn ich mehr als nur abstimmen könnte, wäre Ihre Antwort und Bewertung genauso korrekt wie ich.

— Ben Griswold

@Marc Gravell: Kennen Sie zufällig VS-Erweiterungen, die die Funktionalität zum Festlegen von DependentUpon für Dateien bieten?

— Dyppl

@Dyppl Die FileNesting Erweiterung kann dies tun

— gt

Um die Antwort von Marc Gravell ♦ zu ergänzen, hatte ich eine Situation mit Dateien in einem Unterordner und dem DependentUponKnoten, der ignoriert wurde. Das kurze daran ist, dass in einem solchen Fall meine XML sein musste:

<Compile Include="foo\bar.cs" />
<Compile Include="foo\bar.baz.cs">
    <DependentUpon>bar.cs</DependentUpon>  <!-- Note that I do not reference the subfolder here -->
</Compile>

Ich hoffe das hilft jemandem :)

— Namenloser
quelle

ich auch. Dies geschah, weil ich das Projekt zuerst in der Datenbank gestartet habe und es beim Erstellen des Modells in das Modelldiagramm eingefügt habe. VS2015, wenn es für jemanden einen Unterschied macht.

— Joshua K