.NET: Comment décidez-vous comment structurer vos espaces de noms?

Je me demande quelles directives vous utilisez pour déterminer la structure de vos espaces de noms. Quand décidez-vous que quelque chose mérite son propre Namespace? J'ai lu dans un forum de discussion ou d'article que la meilleure pratique est d'opter pour un arbre peu profond avec aussi peu d'espaces de noms que possible, mais je ne peux pas me rappeler le raisonnement qui le sous-tend ou le lien..NET: Comment décidez-vous comment structurer vos espaces de noms?

Maintenant, je fais juste ce qui "se sent bien", mais je préférerais des lignes directrices plus concrètes, en particulier pour expliquer aux nouveaux développeurs.

Merci.

Source

2009-10-19 Fung

Microsoft a guidelines on namespace naming, here too .. Brad Abrams has his thoughts.

Source

2009-10-19 02:45:37

@Nicholas. Je suis plus intéressé par la façon de structurer votre arborescence Namespace plutôt que le nom réel. Par exemple. Si vous écrivez un paquet d'analyseurs qui héritent d'un analyseur de base, placeriez-vous tous les analyseurs dans un espace de noms ou créeriez-vous un sous-espace de noms pour chaque analyseur sous-classé? Ce genre de chose. – Fung

Je comprends, mais c'est une question tellement ouverte. Je peux vous indiquer ce que disent les experts/les concepteurs, mais au final, c'est à vous (ou à votre équipe) de développer votre style. Qu'est-ce qui fonctionne le mieux? Qu'est-ce qui a le plus de sens? –

Je vais pour l'approche de l'arbre peu profond, moi-même. L'une des conséquences négatives des espaces de noms à plusieurs couches est la prolifération de classes identiques et identiques dans un même projet (différenciées uniquement par leurs différents emplacements d'espaces de noms), ou pire: différemment -functioned classes dans le même projet. Avoir seulement un seul espace de noms dans un projet force les développeurs à donner à chaque classe séparée un bon nom auto-descriptif. Disposer de multiples dossiers dans un projet est toujours une bonne idée, cependant (pour des raisons d'organisation), et je souhaite qu'il y avait une option dans Visual Studio telle que les classes ajoutées dans un sous-dossier ne puissent pas avoir automatiquement le dossier noms ajoutés à leurs espaces de noms (il peut y avoir une telle option dans les versions plus récentes que 2005). Je contourne cela en ajoutant toujours de nouvelles classes au niveau de la racine, puis en les faisant glisser dans leurs dossiers appropriés.

Source

2009-10-19 02:59:35 MusiGenesis

J'utilise plusieurs dossiers (dossiers à plusieurs niveaux) dans la solution et parfois dans des projets.

Je mappe des dossiers de solution sur des espaces de noms, ce qui donne parfois aux projets un sous-espace de noms.

La plupart de mes projets ont un espace de nom.

E.g.

Company.Product.Initialization // (exe project) 
Company.Product.Data.Interfaces // interfaces (dll) 
Company.Product.Data.Collections // collections (dll) 
Company.Product.Data.Binding // binding logic (dll) 
Company.Product.Data.Binding.Tests // unit tests for above (dll) 
Company.Product.Data.Serialization 
Company.Product.Data.Serialization.Tests 
Company.Product.Model // (dlls) 
Company.Product.Gui.Controls // (dlls) 
Company.Product.Gui.Windows // (dlls) 
Company.Product.Gui.ModelView // (dlls) 
Company.Product.Gui.Logic // (dlls)

Je suis d'accord avec MusiGenesis sur l'importance de bons noms et suggérons aussi de lire les directives de MS (de préférence pour C# 3.5 ou 4.0 si).

Source

2009-10-25 23:24:43

.NET: Comment décidez-vous comment structurer vos espaces de noms?

Répondre

Questions connexes