2009-10-15 9 views
0

Eh bien, je viens de faire mon projet assez grand et utilisé correctement l'espace de nommage (dans les conventions de nommage) donc j'avoir des choses comme modèles, le service, l'interface utilisateur etc .... tous les trucs standards ..Recommandations d'espace de nom pour la tenue d'énumérations?

et moi avons DRAWN A BLANK :-) !! J'ai un certain nombre d'énumérations, de constantes et de choses comme ça dont j'ai besoin pour les extraire d'une classe générique que j'ai et les insérer dans une classe/projet de leur propre afin que je puisse ajouter une référence à tous mes les projets qui en ont besoin.

Quelqu'un peut-il suggérer une bonne convention de nommage pour la tenue des énumérations et des constantes etc .. Je pensais à l'aide CompanyName.Product.Enumerations mais là encore ses pas seulement énumérations ..

J'espérais un peu d'entrée ou conseille et bon espace de noms pour la structure nommant ce type de projet (holding énumération, des collections et des constantes)

Merci à l'avance

Répondre

0

Eh bien, habituellement, je recommande de ne pas les séparer. Les mêmes règles s'appliquent pour les raisons pour lesquelles je n'aime pas les projets "boîte à outils" qui finissent comme dump-code. Vous ne pouvez pas laisser simplement vos autres projets référencer votre assemblage actuel?

Il semble que vous sépariez des éléments qui sont essentiels à vos règles de gestion, pourquoi ne pas tirer le nom de cette zone?

+0

Vrai mais j'ai 2 projets, l'un est un projet de classe de base et l'autre en hérite ... donc les deux doivent avoir accès aux mêmes enums , constantes –

+0

pourquoi ne pas les mettre dans le projet de classe de base? –

2

les énumérations doivent vivre dans le même espace que les types qui les utilisent - ne pas créer des espaces de noms qui organisent les choses par la façon dont elles sont conçues.

Pensez simplement - créeriez-vous des espaces de noms comme celui-ci?

Comp.Project.Classes 
Comp.Project.Structs 
Comp.Project.Interfaces 

Non, car cela ne signifie rien et ne fournit aucune information contextuelle sur les types qui y sont contenus. Les énumérations sont comme n'importe quel autre type - elles appartiennent à un espace de noms qui a une signification contextuelle pour l'énumération elle-même.

+0

Merci, oui très vrai, mais le problème est que j'ai 2 projets, l'un est projet de base/classe ... - l'un hérite de l'autre mais a des méthodes à l'intérieur qui ne peut pas être remplacé ... La base et la classe héritée ont des méthodes qui ont besoin d'accéder aux mêmes énumérations, constantes, etc. –

0

Peut-être quelque chose comme CompanyName.Product.Reference en tant que assemblyname, puis spécifier plus loin en utilisant Reference.Constants, Reference.Enums etc?

Questions connexes