Consignes relatives aux espaces de noms et aux noms de classe

15

J'ai des problèmes pour nommer correctement mes classes et services lorsque des utilitaires et autres classes d'aide sont impliqués.

Comment structureriez-vous les éléments suivants:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

etc...

J'ai plusieurs services avec les mêmes besoins que le service ci-dessus. Une idée est de séparer tout cela dans un espace de noms approprié, en le faisant ressembler à ceci:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

etc. Chaque espace de noms est bien sûr un dossier séparé. Mais cela ne semble pas à 100%, car il y en a probablement plus DateValidatorsdans les autres services, ce qui peut facilement conduire à une référence indésirable.

Et le Services.EventService.EventService.csinclut également le nom de classe dans l'espace de noms, ce qui n'est pas bon non plus. Vous pouvez utiliser Services.Event.EventService.cs, mais il existe bien sûr déjà une entité avec ce nom.

Ceci est le modèle de domaine.

c# architecture Mattias
la source
"J'ai plusieurs services avec les mêmes besoins que le service ci-dessus." Cela signifie-t-il que plusieurs services utilisent le code ci-dessus ou que plusieurs services doivent fournir leur propre version en suivant le même modèle?
Nathanael
Qu'ils fournissent leur propre version du même modèle
Mattias

Réponses:

5

Je pense que la plus grande chose que vous puissiez faire pour améliorer votre espace de noms ici est de supprimer Servicede votre EventServiceespace de noms. J'ajusterais également les espaces de noms pour qu'ils ressemblent davantage à ceci:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Je pense toujours que cela pourrait utiliser une amélioration.

J'aimais les espaces de noms, mais aujourd'hui, je pense que moins c'est plus. L'imbrication profonde de vos espaces de noms peut rendre votre code trop verbeux, et décomposer les choses jusqu'à présent réduit considérablement votre capacité d'héritage. Dans votre code par exemple, une DateValidatorclasse pourrait facilement être utilisée ailleurs, donc elle ne devrait pas avoir beaucoup d'espaces de noms au-dessus, car des services autres que EventService peuvent désormais tirer parti d'une classe DateValidator. Il en va de même pour les méthodes d'extension. Il n'y a pas de temps (que je puisse voir) où vous auriez besoin de voir toutes vos méthodes d'extension en même temps, il est donc plus logique de le regrouper avec la chose à laquelle il se rapporte. Dans ce cas, EventExtensionsprobablement des liens vers les vôtres EventService, donc logiquement ils devraient s'asseoir ensemble à mon avis.

Karl Nicoll
la source
Le projet est trop grand pour ne pas le décomposer à un certain niveau. Le DateValidator sous l'espace de noms d'événement ne gère que les cas spécifiques à l'événement et ne peut donc pas être utilisé ailleurs. J'aime les services. Evénements .EventService. Comment pourrais-je ne pas penser à ça. Je pense qu'il est temps de refactoriser!
Mattias
@Mattias - C'est juste. Pour autant que je puisse voir, l'espace de noms (au-delà des directives de base telles que celles mentionnées par Saeed ci-dessous) est à peu près une question de goût.
Karl Nicoll
2

Une conception appropriée de l'espace de noms prendra en compte la conception logique et physique.

Bien que la raison d'être des espaces de noms était principalement de prévenir les conflits de noms entre les noms d'objet et de méthode, il est devenu un élément important dans l'architecture et la conception globales de la solution. Non seulement vous voulez que votre hiérarchie conceptuelle et votre conception logique aient un sens, mais vous voulez aussi que votre code soit soigneusement rangé dans des bibliothèques bien conçues et facilement réutilisables qui peuvent être facilement regroupées dans d'autres projets et produits plus tard. C'est peut-être davantage le résultat souhaité d'une bonne conception physique.

Regardez le .NET Framework et comment les unités de fonctionnalités associées vous sont données dans des assemblages de taille raisonnable. Vous pouvez ajouter une référence et une déclaration d'utilisation et tout à coup, vous disposez de fonctionnalités pertinentes sans avoir à glisser dans un certain nombre d'éviers de cuisine. Cela est dû au fait que la conception physique du .NET Framework, y compris l'espace de noms intelligent, a empaqueté du code lié logiquement dans des unités déployables physiquement liées. En créant un excellent mappage entre les espaces de noms et les assemblys, les architectes et les développeurs du framework .NET de Microsoft ont rendu votre travail beaucoup plus facile (bien sûr, certains peuvent argumenter le contraire, mais je suis plutôt satisfait de ce qu'ils ont fait).

L'espace de noms en C # est plutôt arbitraire. Vous pouvez placer des espaces de noms dans les endroits les plus étranges, dans des assemblages éloignés les uns des autres. Toute discipline utile dans ce domaine est vraiment votre contribution personnelle à un produit logiciel bien organisé. Je n'oserais pas vous conseiller exactement quoi faire dans chaque cas. Ce que j'espère accomplir, dans cette réponse, est de vous faire penser à la conception physique ainsi qu'à la conception logique lorsque vous définissez vos espaces de noms. Plus vous gardez les choses logiquement liées et déployées (physiquement), plus les choses seront faciles plus tard, à la fois pour vous et pour les autres qui pourraient avoir besoin de gérer votre code un jour.

Alors, pensez à la façon dont votre code sera empaqueté dans les assemblys et les composants lorsque vous résolvez vos problèmes d'espaces de noms!

John Tobler
la source