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 l'un des projets de mes équipes, nous avons une bibliothèque de classes qui contient de nombreux sous-dossiers dans le projet.

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

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

• dossier Vehicles a cours dans l'espace de noms MyCompany.Project.Section.Vehicles
• dossier Clothing a des classes dans l'espace de noms MyCompany.Project.Section.Clothing
• etc.

A l'intérieur de ce même projet, il y a un autre dossier non autorisé

• dossier BusinessObjects a des classes dans l'espace de noms MyCompany.Project.Section

Il y a quelques cas comme celui-ci où les dossiers sont faits pour « faciliter l'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 mélangé?

Answer 1

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 classes seront plus faciles à trouver et cela seul devrait être des raisons assez bonnes.

Les règles que nous suivons sont:

• Nom du projet/assemblage est le même que l'espace de noms racine, à l'exception de la .dll se termine
• Seule exception à la règle ci-dessus est un projet avec un .Core fin, le .Core est enlevé
• dossiers est égal à namespaces
• Un type par fichier (classe, struct, enum, délégué, etc.) il est facile de trouver le bon fichier

Answer 2

Oui, ils devraient, ne mène à la confusion autrement.

Answer 3

Je dirais que oui. Tout d'abord, il sera plus facile de trouver les fichiers de code réels en suivant les espaces de noms (par exemple, quand quelqu'un vous envoie un e-mail d'une pile d'appels d'exception nue). Si vous laissez la désynchronisation de vos dossiers avec les espaces de noms, trouver des fichiers dans des bases de code importantes devient fatiguant. En second lieu, VS générera de nouvelles classes que vous créez dans des dossiers avec le même espace de noms de la structure de dossiers parents. Si vous décidez de nager contre cela, ce sera juste un travail de plus de plomberie à faire tous les jours lors de l'ajout de nouveaux fichiers. Bien sûr, cela va sans dire que l'on doit être prudent sur la profondeur de la hiérarchie des dossiers/espaces de noms de xis.

Answer 4

Je pense que la norme, au sein de .NET, est d'essayer de le faire lorsque c'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 l'espace de noms == 100% du temps, parfois c'est juste plus propre/mieux 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.

Answer 5

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

Lorsque j'ai des classes imbriquées, je les sépare encore, 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 6

n °

J'ai essayé les deux méthodes sur les petits et les grands projets, à la fois avec un seul (moi) et une équipe de développeurs. J'ai trouvé que le chemin le plus simple et le plus productif é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 mettre les fichiers de classe dans les dossiers de projet que vous voulez. Il n'y a aucun inconvénient à ajouter des instructions using en haut des dossiers tout le temps car il y a juste un seul espace de noms.

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

Prenez cet avertissement FxCop par exemple:

CA1020: Évitez les espaces de noms avec quelques 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 Project.General générique, ou même dans la racine du projet jusqu'à ce que vous ayez quatre classes similaires pour justifier la création d'un nouveau fichier. w dossier. Est-ce que cela arrivera jamais?

Recherche de fichiers

La réponse acceptée dit « Les classes seront plus faciles à trouver et que seul doit être des raisons assez bon. »

Je suppose que la réponse fait référence à plusieurs espaces de noms dans un projet qui ne correspondent pas à la structure du dossier, plutôt que ce que je suggère qui est un projet avec un seul espace de noms.

Dans tous les cas, même si vous ne pouvez pas déterminer dans quel dossier se trouve un fichier de classe à partir de l'espace de noms, vous pouvez le rechercher à l'aide de la commande Aller à la définition. Aussi 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 trouver des fichiers pour justifier l'optimisation.

Nom des affrontements

Bien sûr la création de plusieurs espaces de noms permet projet d'avoir deux classes avec le même nom. Mais est-ce vraiment une bonne chose? Est-il peut-être plus facile d'empêcher cela d'être possible? Permettre 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 trouvez que vous avez un cas spécial. Disons que vous avez deux classes Rectangle définies dans les espaces de noms distincts:

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

Il est possible de frapper un problème qu'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 instruction à l'aide bandante:

using Rectangle = Project1.Window.Rectangle; 

Avec un seul espace de noms dans votre projet, vous êtes obligé de trouver avec différents, et je dirais plus descriptif, des noms comme ceci:

• classe Project1.ImageRectangle
• classe Project1.WindowR ectangle

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

utilisant 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 namespaces tout le temps alors que le code écrit. Ce n'est pas le temps que cela prend vraiment, c'est la rupture du flux de devoir le faire et juste remplir des fichiers avec beaucoup d'utilisation des déclarations - pour quoi faire? Est-ce que ça vaut le coup?

Modification de la structure des dossiers de projet

Si les dossiers sont mis en correspondance avec les espaces de noms, puis le chemin du dossier de projet est effectivement codé en dur dans chaque fichier source. Cela signifie que tout changement de nom ou de déplacement d'un fichier ou d'un dossier dans le projet nécessite un changement du contenu du fichier. La déclaration de l'espace de noms des fichiers dans ce dossier et l'utilisation des instructions dans un tas d'autres fichiers qui référencent les classes dans ce dossier. Bien que les changements eux-mêmes soient triviaux avec l'outillage, il en résulte généralement un grand 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 du dossier de projet comme vous le souhaitez sans que les fichiers source eux-mêmes soient modifiés.

Visual Studio associe automatiquement l'espace de noms d'un nouveau fichier dans le dossier du projet, il est créé dans

Malheureux, mais je trouve les tracas de corriger l'espace de noms est inférieure à les tracas de traiter avec eux. J'ai aussi l'habitude de copier coller un fichier existant plutôt que d'utiliser Ajouter-> Nouveau.

IntelliSense et Explorateur d'objets

Le plus grand avantage à mon avis d'utiliser plusieurs espaces de noms dans les grands projets est d'avoir l'organisation supplémentaire lors de l'affichage des cours dans tous les outils qui affiche des classes dans une hiérarchie des espaces de noms. Même la documentation. Évidemment, le fait d'avoir 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é décontenancé ou retardé à cause d'un manque de ceci, donc je ne trouve pas cela un avantage suffisant pour justifier plusieurs espaces de noms.

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