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

Question

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

Dans un des projets de mon équipe, nous avons une bibliothèque de classes qui a de nombreux sous-dossiers dans le projet.

Nom du projet et espace de nommage : MyCompany.Project.Section .

Dans ce projet, il y a plusieurs dossiers qui correspondent à la section espace de noms :

• Dossier Vehicles a des cours dans le MyCompany.Project.Section.Vehicles espace de noms
• Dossier Clothing a des cours dans le MyCompany.Project.Section.Clothing espace de noms
• etc.

Dans ce même projet, il y a un autre dossier malveillant.

• Dossier BusinessObjects a des cours dans le MyCompany.Project.Section espace 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 la suivante : 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 est-ce un mélange des deux ?

Answer 1

Notez également que si vous utilisez les modèles intégrés pour ajouter des classes à un dossier, celles-ci seront placées par défaut dans un espace de nom qui reflète la hiérarchie du dossier.

Les classes seront plus faciles à trouver et cela seul devrait être une raison suffisante.

Les règles que nous suivons sont :

• Le nom du projet/assemblage est identique à celui de l'espace de nom Root, à l'exception de la terminaison .dll.
• La seule exception à la règle ci-dessus est un projet avec une terminaison .Core, le .Core est supprimé.
• Les dossiers équivalent aux espaces de noms
• Un seul type par fichier (classe, struct, enum, délégué, etc.) permet de trouver facilement le bon fichier.

Answer 2

Non.

J'ai essayé les deux méthodes sur des petits et grands projets, 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 nom par projet et toutes les classes vont dans cet espace de nom. Vous êtes ensuite libre de placer les fichiers de classe dans les dossiers de projet de votre choix. Il n'y a pas à s'embêter à ajouter des déclarations d'utilisation en haut des fichiers tout le temps puisqu'il n'y a qu'un seul espace de nom.

Il est important d'organiser les fichiers sources dans des dossiers et, à mon avis, c'est tout ce à quoi les dossiers devraient servir. Exiger que ces dossiers correspondent également à des espaces de noms n'est pas nécessaire, crée plus de travail, et j'ai trouvé que cela était en fait nuisible à l'organisation parce que la charge supplémentaire encourage la désorganisation.

Prenez cet avertissement de 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 déversement de nouveaux fichiers dans un dossier générique Project.General, ou même dans 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 un jour ?

Recherche de fichiers

La réponse acceptée est la suivante : "Les classes seront plus faciles à trouver et cela seul devrait être une raison suffisante".

Je pense que la réponse fait référence au fait d'avoir plusieurs espaces de noms dans un projet qui ne correspondent pas à la structure des dossiers, plutôt que 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 la fonction "Go To Definition" ou la boîte de recherche de l'explorateur de solutions dans Visual Studio. De plus, ce n'est pas vraiment 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 ? Ne serait-il pas plus simple d'interdire cette possibilité ? 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 et puis soudainement vous découvrez que vous avez un cas spécial. Disons que vous avez deux classes Rectangle définies dans des espaces de noms distincts :

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

Il est possible de se heurter au fait qu'un fichier source doit inclure les deux espaces de noms. Vous devez alors écrire l'espace de nom complet partout dans ce fichier :

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

Ou de s'amuser avec une déclaration d'utilisation méchante :

using Rectangle = Project1.Window.Rectangle;

Avec un seul espace de nom dans votre projet, vous êtes obligé de trouver 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 à gérer un cas particulier lorsqu'un fichier utilise les deux types.

utilisation des déclarations

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

vs

using Project1;

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

Modification de la structure des dossiers du projet

Si les dossiers sont mappés aux espaces de noms, le chemin du dossier du projet est effectivement codé en dur dans chaque fichier source. Cela signifie que tout renommage ou déplacement d'un fichier ou d'un dossier dans le projet exige que le contenu réel du fichier soit modifié. Il s'agit à la fois de la déclaration de l'espace de nom des fichiers de ce dossier et des instructions d'utilisation dans un grand nombre d'autres fichiers qui font référence aux classes de ce dossier. Bien que les modifications elles-mêmes soient triviales avec les outils, 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 nom dans le projet, vous pouvez modifier la structure des dossiers du projet comme vous le souhaitez sans que les fichiers sources eux-mêmes soient modifiés.

Visual Studio associe automatiquement l'espace de nom d'un nouveau fichier au dossier du projet dans lequel il est créé.

C'est regrettable, mais je trouve que la correction de l'espace de noms est moins pénible que le fait de s'occuper d'eux. De plus, j'ai 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 les grands projets est d'avoir une organisation supplémentaire lors de la visualisation des classes dans tout outil qui affiche les classes dans une hiérarchie d'espaces de noms. Même la documentation. Évidemment, le fait de n'avoir qu'un seul espace de noms dans le projet fait que toutes les classes sont affichées dans une seule liste plutôt que d'être divisées en catégories. Cependant, personnellement, je n'ai jamais été bloqué ou retardé à cause d'un manque de cela, donc je ne trouve pas que ce soit un avantage suffisamment important pour justifier plusieurs espaces de noms.

Bien que si j'écrivais une grande bibliothèque de classes publiques, alors je serait probablement utiliser plusieurs espaces de noms dans le projet pour que l'assemblage ait un aspect soigné dans l'outillage et la documentation.

Answer 3

Je pense que la norme, dans .NET, est d'essayer de le faire quand c'est possible, mais de ne pas 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 espace de noms == structure 100% du temps, parfois il est juste plus propre/meilleur de s'affranchir de telles règles.

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

Answer 4

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

Lorsque j'ai des classes imbriquées, je les sépare toujours, une par fichier. Comme ceci :

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

et

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

Answer 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 les nouvelles classes que vous créez dans des dossiers ayant le même espace de nom que la structure de son dossier parent. Si vous décidez de nager à contre-courant, ce sera juste un travail de plomberie de plus à faire quotidiennement lors de l'ajout de nouveaux fichiers.

Bien entendu, il va sans dire qu'il faut être prudent quant à la profondeur de la hiérarchie des dossiers/espaces de noms de xis.