Les dossiers d'une solution doivent-ils correspondre à l'espace de noms?

129

Les dossiers d'une solution doivent-ils correspondre à l'espace de noms?

Dans l'un de mes projets d'équipe, nous avons une bibliothèque de classes qui contient de nombreux sous-dossiers dans le projet.

Nom du projet et Namespace: MyCompany.Project.Section.

Dans ce projet, il existe plusieurs dossiers qui correspondent à la section d'espace de noms:

  • Le dossier Vehiclesa des classes dans l' MyCompany.Project.Section.Vehiclesespace de noms
  • Le dossier Clothinga des classes dans l' MyCompany.Project.Section.Clothingespace de noms
  • etc.

À l'intérieur de ce même projet, se trouve un autre dossier non autorisé

  • Le dossier BusinessObjectsa des classes dans l' MyCompany.Project.Sectionespace de noms

Il existe quelques cas comme celui-ci où les dossiers sont créés pour des raisons de "commodité d'organisation".

Ma question est: quelle est la norme? Dans les bibliothèques de classes, les dossiers correspondent-ils généralement à la structure de l'espace de noms ou s'agit-il d'un sac mixte?

Marius Bancila
la source
9
Remarque: ReSharper se plaindra si les espaces de noms ne correspondent pas à la hiérarchie des dossiers.
Fred

Réponses:

77

Notez également que si vous utilisez les modèles intégrés pour ajouter des classes à un dossier, il sera par défaut placé dans un espace de noms qui reflète la hiérarchie des dossiers.

Les cours seront plus faciles à trouver et cela seul devrait être des raisons suffisantes.

Les règles que nous suivons sont:

  • Le nom du projet / de l'assembly est le même que celui de l'espace de noms racine, à l'exception de la fin .dll
  • La seule exception à la règle ci-dessus est un projet avec une fin .Core, le .Core est supprimé
  • Les dossiers sont égaux aux espaces de noms
  • Un type par fichier (classe, struct, enum, délégué, etc.) permet de trouver facilement le bon fichier
Lasse V. Karlsen
la source
1
+1 pour "La seule exception à la règle ci-dessus est un projet avec une fin .Core, le .Core est supprimé" seul. J'ai une MyProject.Core.dllassemblée et toutes les classes commencent par MyProject.Core. Supprimer le .Coresuffixe a beaucoup plus de sens.
Luiz Damim
2
Une autre exception que je pourrais ajouter concerne les exceptions. Les exceptions sont déjà suffixées avec «Exception», donc un espace de noms supplémentaire est redondant. Cela peut également être compliqué d'avoir une partie de l'espace de noms avec le mot Exception (peut conduire à confondre System.Exception). Cependant, les organiser dans des dossiers est très utile.
phillipwei
55

Non.

J'ai essayé les deux méthodes sur de petits et grands projets, à la fois avec un seul (moi) et une équipe de développeurs.

J'ai trouvé que la voie la plus simple et la plus productive était d'avoir un seul espace de noms par projet et toutes les classes vont dans cet espace de noms. Vous êtes alors libre de placer les fichiers de classe dans les dossiers de projet de votre choix. Il n'y a pas de problème à ajouter en permanence des instructions using en haut des fichiers car il n'y a qu'un seul espace de noms.

Il est important d'organiser les fichiers source dans des dossiers et à mon avis, tous les dossiers devraient être utilisés. Il n'est pas nécessaire d'exiger que ces dossiers soient également mappés aux espaces de noms, cela crée plus de travail, et j'ai trouvé que cela nuisait à l'organisation car le fardeau supplémentaire encourage la désorganisation.

Prenez cet avertissement FxCop par exemple:

CA1020: éviter les espaces de noms avec peu de types
cause: Un espace de noms autre que l'espace de noms global contient moins de cinq types https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Cet avertissement encourage le vidage de nouveaux fichiers dans un dossier générique Project.General, ou même la racine du projet jusqu'à ce que vous ayez quatre classes similaires pour justifier la création d'un nouveau dossier. Cela arrivera-t-il jamais?

Recherche de fichiers

La réponse acceptée dit: "Les classes seront plus faciles à trouver et cela seul devrait être des raisons suffisantes."

Je soupçonne que la réponse fait référence à la présence de plusieurs espaces de noms dans un projet qui ne correspondent pas à la structure de dossiers, plutôt qu'à ce que je suggère, à savoir un projet avec un seul espace de noms.

Dans tous les cas, même si vous ne pouvez pas déterminer le dossier dans lequel se trouve un fichier de classe à partir de l'espace de noms, vous pouvez le trouver en utilisant Atteindre la définition ou la zone Explorateur de solutions de recherche dans Visual Studio. Ce n'est pas non plus un gros problème à mon avis. Je ne consacre même pas 0,1% de mon temps de développement au problème de la recherche de fichiers pour justifier son optimisation.

Conflits de noms

Bien sûr, la création de plusieurs espaces de noms permet au projet d'avoir deux classes avec le même nom. Mais est-ce vraiment une bonne chose? Est-il peut-être plus facile de simplement empêcher que cela soit possible? Autoriser deux classes avec le même nom crée une situation plus complexe où 90% du temps, les choses fonctionnent d'une certaine manière, puis soudainement vous découvrez que vous avez un cas particulier. Supposons que vous ayez deux classes Rectangle définies dans des espaces de noms séparés:

  • classe Project1.Image.Rectangle
  • classe Project1.Window.Rectangle

Il est possible de rencontrer un problème pour lequel un fichier source doit inclure les deux espaces de noms. Maintenant, vous devez écrire l'espace de noms complet partout dans ce fichier:

var rectangle = new Project1.Window.Rectangle();

Ou déconner avec une déclaration d'utilisation désagréable:

using Rectangle = Project1.Window.Rectangle;

Avec un seul espace de noms dans votre projet, vous êtes obligé de proposer des noms différents, et je dirais plus descriptifs, comme celui-ci:

  • classe Project1.ImageRectangle
  • classe Project1.WindowRectangle

Et l'utilisation est la même partout, vous n'avez pas à faire face à un cas particulier lorsqu'un fichier utilise les deux types.

utiliser des instructions

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

contre

using Project1;

La facilité de ne pas avoir à ajouter des espaces de noms tout le temps lors de l'écriture de code. Ce n'est pas vraiment le temps que cela prend, c'est la rupture du flux de devoir le faire et juste de remplir des fichiers avec beaucoup d'instructions d'utilisation - pour quoi? Est-ce que ça vaut le coup?

Modification de la structure des dossiers de projet

Si les dossiers sont mappés à des espaces de noms, le chemin du dossier du projet est effectivement codé en dur dans chaque fichier source. Cela signifie que tout changement de nom ou tout déplacement d'un fichier ou d'un dossier dans le projet nécessite la modification du contenu réel du fichier. À la fois la déclaration d'espace de noms des fichiers dans ce dossier et les instructions using dans tout un tas d'autres fichiers qui référencent des classes dans ce dossier. Bien que les changements eux-mêmes soient triviaux avec l'outillage, il en résulte généralement un gros commit composé de nombreux fichiers dont les classes n'ont même pas changé.

Avec un seul espace de noms dans le projet, vous pouvez modifier la structure des dossiers du projet comme vous le souhaitez sans qu'aucun fichier source lui-même ne soit modifié.

Visual Studio mappe automatiquement l'espace de noms d'un nouveau fichier au dossier de projet dans lequel il a été créé

Malheureusement, mais je trouve que la correction de l'espace de noms est moins que celle de les gérer. J'ai également pris l'habitude de copier-coller un fichier existant plutôt que d'utiliser Ajouter-> Nouveau.

Intellisense et navigateur d'objets

Le plus grand avantage à mon avis de l'utilisation de plusieurs espaces de noms dans de grands projets est d'avoir une organisation supplémentaire lors de l'affichage des classes dans n'importe quel outil qui affiche les classes dans une hiérarchie d'espaces de noms. Même documentation. Évidemment, le fait de n'avoir qu'un seul espace de noms dans le projet entraîne l'affichage de toutes les classes dans une seule liste plutôt que de les diviser en catégories. Cependant, personnellement, je n'ai jamais été perplexe ou retardé à cause d'un manque de cela, donc je ne trouve pas que cela soit un avantage suffisamment important pour justifier plusieurs espaces de noms.

Bien que si je devais écrire une grande bibliothèque de classe publique alors je serais probablement utiliser plusieurs espaces de noms dans le projet afin que l'ensemble soigné dans l' air de l'outillage et de la documentation.

Weyland Yutani
la source
30
C'est honnêtement l'une des solutions les plus cauchemardesques que j'ai entendues suggérées. Si vous travaillez sur de petits projets hello world, ce conseil fonctionne, mais imaginez que vous avez plus de 1000 fichiers .cs. Cela causerait tellement de problèmes que je ne sais pas par où commencer.
BentOnCoding
10
"mais imaginez que vous avez plus de 1000 fichiers .cs". J'ai travaillé sur des projets de cette taille avec un seul espace de noms. C'est bon. Selon vous, quel désastre se produirait?
Weyland Yutani
14
+1 pour réfléchir. Je ne pense pas être prêt à réduire mes espaces de noms à un par projet, mais après avoir travaillé sur un grand framework, j'explore la réduction du nombre d'espaces de noms pour réduire le nombre d'instructions using et pour faciliter la découverte des méthodes d'extension. Je pense que cette réponse donne matière à réflexion. Merci.
Lee Gunn
3
@WeylandYutani je sais que je suis en retard mais je dois mentionner que cette phrase: you can find it by using Go To Definition or the search solution explorer box in Visual Studion'est pas toujours vraie. Essayez-le avec beaucoup d'héritage et d'interfaces ... bonne chance pour trouver le bon fichier.
Emmanuel M.
11
C'est l'un des meilleurs conseils que j'ai vus. Les espaces de noms sont uniquement destinés à la résolution des conflits, pas à l'organisation des classes. N'utilisez les espaces de noms que là où il est judicieux de les utiliser, par exemple là où vous prévoyez avoir des conflits de noms avec d'autres projets susceptibles d'utiliser votre projet, ce qui permet d'inclure ou d'exclure certains espaces de noms avec des instructions using. C'est terrible d'avoir un projet avec 3 ou 4 espaces de noms ou plus fréquemment utilisés, car il en résulte toujours un nombre ridicule d'instructions d'utilisation que vous devez ajouter et ajouter et ajouter et ajouter. Séparez vos projets.
Triynko
31

Je pense que la norme, dans .NET, est d'essayer de le faire lorsque cela est possible, mais pas de créer des structures inutilement profondes juste pour y adhérer comme une règle stricte. Aucun de mes projets ne suit la règle de structure de l'espace de noms == 100% du temps, parfois il est juste plus propre / mieux de sortir de ces règles.

En Java, vous n'avez pas le choix. J'appellerais cela un cas classique de ce qui fonctionne en théorie par rapport à ce qui fonctionne dans la pratique.

Karl Seguin
la source
1
Je dirais "faites-le quand vous voulez vraiment que quelque chose soit dans son propre espace de noms". Ce devrait être une décision consciente. Si vos projets sont correctement isolés, il doit y avoir un espace de noms par projet. Si votre classe se trouve dans un espace de noms, elle doit être dans un dossier avec cet espace de noms OU un emplacement de sous-dossier qui est au moins aussi spécifique que l'espace de noms. Une classe comme Car.Ford.Fusion (si Car.Ford est votre seul espace de noms) doit être dans un dossier comme Car / Ford OU plus profond comme Car / Ford / Sedans, de sorte que le dossier soit au moins aussi spécifique que l'espace de noms. Ne le mettez pas simplement dans Car / Unrelated / Ford; c'est déroutant.
Triynko
25

@lassevk: Je suis d'accord avec ces règles et j'en ai une de plus à ajouter.

Quand j'ai des classes imbriquées, je les divise toujours, une par fichier. Comme ça:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

et

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}
Jay Bazuzi
la source
5

Je dirais oui.

Premièrement, il sera plus facile de trouver les fichiers de code réels en suivant les espaces de noms (par exemple, lorsque quelqu'un vous envoie par e-mail une pile d'appels d'exception nue). Si vous laissez vos dossiers se désynchroniser avec les espaces de noms, trouver des fichiers dans de grandes bases de code devient fatigant.

Deuxièmement, VS générera de nouvelles classes que vous créez dans des dossiers avec le même espace de noms que sa structure de dossiers parent. Si vous décidez de nager contre cela, ce ne sera plus qu'un travail de plomberie à faire quotidiennement lors de l'ajout de nouveaux fichiers.

Bien sûr, cela va sans dire qu'il faut être prudent sur la profondeur de la hiérarchie des dossiers / espaces de noms xis.

Ismaël
la source
4

Oui, ils devraient, ne conduit qu'à la confusion autrement.

Dan
la source
2

Quelle est la norme?

Il n'y a pas de norme officielle, mais par convention, le modèle de mappage dossier-espace de noms est le plus largement utilisé.

Dans les bibliothèques de classes, les dossiers correspondent-ils généralement à la structure de l'espace de noms ou s'agit-il d'un sac mixte?

Oui, dans la plupart des bibliothèques de classes, les dossiers correspondent à l'espace de noms pour faciliter l'organisation.

user1451111
la source