Namespaces correctement assignant (avec les suggestions de ReSharper)

Question

Disons que nous avons le fichier suivant et de la structure [dossier] dans un projet avec un espace de nom principal de MyNamespace:

• [Entités]
  • Article.cs
  • Category.cs
• [Interfaces]
  • IReviewable.cs
  • ISearchable.cs
• Enumerations.cs

Selon les suggestions de ReSharper, l'espace de noms de classes Article et Category devrait être MyNamespace.Entities, l'espace de noms IReviewable et ISearchable devrait être MyNamespace.Interfaces et l'espace de noms pour la classe Enumerations devrait être tout simplement MyNamespace. Cela est dû au fait que les suggestions de ReSharper sont basées sur la structure de dossiers dépendante et que ses suggestions sont basées sur l'emplacement du fichier dans la structure.

---

Que pensez-vous des espaces de noms ci-dessus? Pensez-vous qu'il est correct d'implémenter des espaces de noms pour les classes (interfaces etc ...) uniquement sur leur emplacement de dossier? Ou pensez-vous que la déclaration de l'espace de nom ne doit pas dépendre uniquement de la structure du dossier?

Personnellement, je mettrais tous les fichiers ci-dessus sous le seul MyNamespace car ils sont tous liés les uns aux autres.

Answer 1

Je pense que les suggestions de ReSharper sont bien. Je pense que c'est une erreur de regrouper des classes, etc., par ce qu'ils sont au lieu de ce qu'ils font. Une analogie consiste à regrouper des documents dans des sous-dossiers Word, Excel, etc. au lieu d'un projet ou d'un autre groupement fonctionnel.

Answer 2

Notez que ReSharper ajoute une propriété "Namespace Provider" à chaque dossier de votre projet. Vous pouvez définir cette propriété sur false pour un dossier que vous souhaitez utiliser pour l'organisation, mais pour ne pas contribuer aux espaces de noms.

Answer 3

Il est recommandé d'organiser les fichiers dans des dossiers significatifs et de créer un espace de noms à partir de cette structure. Java suit cette règle depuis de nombreuses années et cela fonctionne pour être bon.

Notez également que lorsque vous avez beaucoup de sous namespaces comme ci-dessus, il est temps d'envisager levelizing comme suggéré par Patrick (bien, vous le connaissez?)

http://codebetter.com/blogs/patricksmacchia/archive/2009/02/15/re-factoring-re-structuring-and-the-cost-of-levelizing.aspx