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

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?

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

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.

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.

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

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.

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

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.