Conventions de dénomination pour les fichiers de classe partielle

Je génère la majeure partie de mon code de génération de modèles ASP.NET MVC. Tous les fichiers générés sont des classes partielles qui utilisent des conventions de dénomination standard. Par exemple, mon fichier de contrôleur d'employé est nommé EmployeeController.cs. Si je souhaite étendre EmployeeController avec une logique personnalisée non générée, je crée un deuxième fichier de classe partiel nommé EmployeeControllerCustom.cs. Je sépare la logique personnalisée et la logique générée en deux fichiers différents afin que la prochaine fois que je génère le EmployeeController, mes modifications personnalisées ne sont pas écrasées. Ajouter le suffixe "Personnalisé" au nom de fichier me semble raisonnable, mais y a-t-il une convention de dénomination de fichier de classe partielle plus établie que je devrais suivre?

c# naming-conventions code-generation partial-classes

— Ben Griswold
source

Réponses:

152

J'utilise la .séparation - par exemple EmployeeController.SomeSpecialBehaviour.cs. Je le lie également dans l'arborescence du projet via "dependUpon" ou quoi que ce soit dans le csproj, de sorte qu'il se niche sous le fichier (dans l'explorateur de solutions) proprement. Vous devez le faire à la main (éditez le csproj) ou avec un addin, cependant; par exemple:

<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>

apparaît comme:

Sous-dossier
- Program.cs
  - Program.Foo.cs

— Marc Gravell
source

La suggestion DependentUpon est vraiment cool et fonctionne très bien. Merci d'avoir noté. Si je lis correctement, vous n'utilisez pas simplement un suffixe standard comme "Personnalisé". Votre suffixe exprime toujours l'intention de la fonctionnalité du fichier de classe partiel. Y a-t-il également une raison pour laquelle vous utilisez le. séparation opposée au boîtier? Est-ce que le. fournir autre chose qu'une meilleure lisibilité? Merci.

— Ben Griswold

Correct - le nom de fichier indique l'intention du code dans cette partie . Donc, si j'implémente une interface exotique (et que je garde le code séparé), cela pourrait l'être SomeType.ICustomTypeDescriptor.cs. Le .(IMO) sépare les deux choses: le type réel ( SomeType) et l'intention ICustomTypeDescriptor- les deux sont déjà entièrement encadrés; en plus, il correspond parfaitement avec des choses comme SomeForm.Designer.cs;-p

— Marc Gravell

Parfait. Merci pour les informations supplémentaires. Si je pouvais faire plus que voter, votre réponse et votre note sont aussi correctes que je le ferais.

— Ben Griswold

@Marc Gravell: connaissez-vous par hasard des extensions VS qui fournissent la fonctionnalité de paramétrage DependentUpon pour les fichiers?

— Dyppl

@Dyppl L' extension FileNesting peut le faire

— gt

Pour ajouter à la réponse de Marc Gravell ♦, j'ai eu une situation avec des fichiers dans un sous-dossier et le DependentUponnœud étant ignoré. Bref, dans un tel cas, mon xml devait être:

<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>

J'espère que ça aidera quelqu'un :)

— Sans nom
source

moi aussi. cela s'est produit parce que j'ai commencé le projet dans la base de données et quand il a créé le modèle, il les a placés dans le diagramme du modèle. VS2015 si cela fait une différence pour quiconque.

— Joshua K