Dois-je arrêter de se battre Visual Studio de l'espace de noms par défaut convention de nommage?

Question

Je suis en train de travailler sur un projet MVVM, donc, j'ai des dossiers dans mon projet, comme les Modèles, les ViewModels, Windows, etc. Chaque fois que je créer une nouvelle classe, Visual Studio ajoute automatiquement le nom du dossier à l'espace de noms de désignation au lieu de simplement garder le projet au niveau de l'espace de noms. Ainsi, l'ajout d'une nouvelle classe pour les Viewmodel dossier résulterait en l'espace de noms, MyProject.ViewModels au lieu de simplement en MyProject.

Lorsque j'ai rencontré, il m'a ennuyé. Mes noms de classe sont assez claires, parfois même contenant le nom du dossier (par exemple, ContactViewModel). J'ai rapidement trouvé moi-même de supprimer manuellement le nom du dossier sur les espaces de noms. J'ai même essayé à un moment donné de créer un modèle de classe (voir cette question), mais je ne pouvais pas obtenir que cela fonctionne, et ils continuaient à le faire manuellement.

J'ai commencé à me demander, cependant, si cette convention existe pour une bonne raison que je suis tout simplement pas voir. Je pouvais voir qu'il est utile si vous pour une raison quelconque a eu beaucoup de jeux, identique à ce que les noms de classes organisées dans des dossiers, mais qui ne semble pas être particulièrement fréquents dans le scénario.

Questions:

• Pourquoi est-il fréquent de la convention pour les noms d'espace de nom pour refléter la structure de dossier?
• Ne vous conformer à cette convention? Pourquoi?

Answer 1

Comme toi, j'ai combattu ce pour le plus de temps. Puis j'ai commencé à examiner pourquoi j'ai créé des dossiers. J'ai trouvé moi-même de commencer à créer des dossiers pour représenter les espaces de noms et de paquets au lieu de l'arbitraire des seaux.

Par exemple, dans un projet MVVM, il pourrait être utile de mettre des points de vue et les modèles de vue dans un autre espace de noms. MVC ont un namespace pour les Modèles, les Contrôleurs et les Vues. Il est également bénéfique pour les cours de groupe par leur fonctionnalité.

Soudain, le projet se sent plus organisé. Il est plus facile pour les autres développeurs à trouver où les fonctionnalités sont mises en œuvre.

Si vous standardisez votre espace de noms pratiques, l'ensemble de vos projets auront le même prévisible de la structure qui sera une grande victoire pour l'entretien.

Answer 2

Si vous voulez de bons conseils, je recommande l'achat Cadre des lignes Directrices de Conception: les Conventions, les Idiomes et les Modèles Réutilisables .Bibliothèques NET qui vous donne tout ce que vous devez savoir sur le cadre réel de l'équipe de conception.

...l'objectif lors de la dénomination des espaces de noms est de créer suffisamment de clarté pour le programmeur qui utilise le framework immédiatement le contenu de l'espace de noms est susceptible d'être...

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

Et surtout

Ne pas utiliser le même nom pour un espace de noms et un type dans cet espace de noms

Fragmentation de tous les 1/2 types dans les espaces de noms ne serait pas répondre à la première exigence que vous auriez un marais de espaces de noms qui devraient être qualifiés ou d'occasion, si vous avez suivi le Visual Studio. Par exemple

De base - Domaine - Les utilisateurs - Les autorisations - Comptes

Voulez-vous créer

• MyCompany.De base.Domaine.Les utilisateurs
• MyCompany.De base.Domaine.Les autorisations
• MyCompany.De base.Domaine.Comptes

ou tout simplement

• MyCompany.De base.Domaine

Pour Visual Studio, ce serait l'ancien. Aussi, si vous utilisez les minuscules fichier/nom de dossier que vous êtes à la recherche à renommer la classe à chaque fois, ainsi que la fabrication d'un grand espace de noms de l'enchevêtrement.

La plupart des il est de bon sens et vraiment à comment vous pouvez vous attendre à voir les espaces de noms organisé, si vous avez été un consommateur de votre propre API ou d'un cadre.

Answer 3

j'ai été choqué par cette, mais de travailler avec et de refactoring projets avec de grandes bases de code rapidement m'a appris le contraire. Ayant embrassé le concept, je pense que c'est une très bonne façon de structurer votre code "physiquement" ainsi que de la logique. Lorsque vous avez un projet de grande envergure et les espaces de noms ne correspondent pas à la les dossiers, il devient difficile de localiser rapidement des fichiers. Il est également beaucoup plus difficile de se rappeler où en sont les choses...

Aussi, si ReSharper le recommande, alors il est probablement une bonne idée. E. g. R# se plaindra si votre classe de l'espace de noms ne correspond pas à son nom de dossier.

Answer 4

Dossiers du système de fichiers et les espaces de noms à la fois représenter une hiérarchie. Je semble tout à fait naturel pour moi de faire correspondre les deux. Je vais même plus loin et d'utiliser une relation 1:1 entre les fichiers et les classes. J'ai même le faire quand je programme dans d'autres langages tels que C++.

Maintenant que vous question de la relation entre ces deux hiérarchies, je me demande sérieusement ce que vous souhaitez représenter par la hiérarchie du système de fichiers.

Answer 5

Une façon de ne pas suivre la convention est de créer le fichier dans le dossier racine du projet et de passer ensuite à la finale de sous-dossier.

De toute façon, c'est une convention en fait, j'aime. Si je suis le fractionnement des types dans des dossiers, puis probablement ces types ont une sorte de regroupement conceptuel lié au dossier. Par conséquent, elle finit par faire un certain sens, de leurs espaces de noms sont aussi similaires. Java prend cette approche et applique avec son système de paquets. La plus grande différence est que VS ne l'est que "suggérer" à vous, puisque ni la langue ou le CLR impose.