Seau de classe. .
https://stackoverflow.com/questions/312565
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Ok, donc j'ai essayé de mettre tout le monde une de mes classes dans un dossier racine, soit:
UI
BusinessLogic
DataAccess
BusinessObjects
Interfaces
j’en ai quelques-uns de plus où je ne peux pas sembler être très seau alors je cherche des suggestions
-
Une classe de cache qui gère un dictionnaire privé et permet un accès différent aux objets en fonction de certaines clés spécifiques
-
Classes d'argument d'événement?
De plus, dans un projet, je commence maintenant à avoir des sous-systèmes qui ont tous les 3 (accès aux données, objets métier, busiensslogic). Comment dois-je briser la structure des dossiers?
A.
ProjectX
--Sous-système1
---- BusinessObjects
---- DataAccess
---- BusinessObjects
--Sous-système2
---- BusinessObjects
---- DataAccess
---- BusinessObjects
ou
ProjectX
--BusienssLogic
---- Sous-système1BL
---- Sous-système2BL
--DataAccess
---- Sous-système1DA
---- Sous-système2DA
--BusinessObjects
---- Sous-système1BO
---- Sous-système2BO
ou
ProjectX
--BusinessLogic
--DataAccess
--BusinessObjects
(sans sous-répertoires pour chaque sous-système fonctionnel)
La solution
J'essaie d'aligner mes noms d'assembly sur leurs espaces de noms et utilise le .NET Framework lui-même comme guide. Je suis fermement convaincu que le fait de travailler avec une structure d’espace de noms menant à une structure de dossiers constitue une base de code beaucoup plus facile à gérer.
Par exemple, j'ai un fournisseur de mise en cache qui fait partie de la structure de développement globale que nous utilisons. Il vit dans un espace de noms similaire à:
[Société] .Core.Data.Caching
J'ai d'autres fonctionnalités liées aux données qui tombent logiquement également sous la fonctionnalité Data. Par conséquent, la mise en cache a des frères et soeurs tels que des adaptateurs, des convertisseurs et des générateurs. Supposons donc que nous ayons les espaces de noms suivants:
[Société] .Core.Data.Adapters
[Société] .Core.Data.Converters
[Société] .Core.Data.Caching
[Société] .Core.Data.Generators
Ces espaces de noms associés résident dans un assemblage appelé [Société] .Core.Data, qui est également le nom du projet. Trouver des choses dans la solution devient très simple en suivant cette structure. En parlant de structure, nous revenons maintenant à la manière dont elles sont stockées sur le disque.
Le nom du projet est le nom du dossier racine. Cela suppose que mon dossier de contrôle de code source, à savoir "C: \ Contrôle source". sur ma machine locale:
C: \ Contrôle de code source \ Core [Société] .Core.Data \
C: \ Source Control \ Core [Société] .Core.Data \ Adapters
C: \ Source Control \ Core [Société] .Core.Data \ Mise en cache
C: \ Source Control \ Core [Société] .Core.Data \ Convertisseurs
C: \ Source Control \ Core [Société] .Core.Data \ Générateurs
Donc, en tant que hiérarchie, cela ressemble à quelque chose comme:
[Solution]
- [Société] .Core.Data
---- [Adaptateurs]
------ (Fichiers adaptateurs)
---- [Caching]
------ (Mise en cache des fichiers)
---- [Convertisseurs]
------ (fichiers convertisseurs)
Je mets tous les projets au même niveau et modifie les sous-espaces de noms avec des dossiers. De cette façon, les espaces de noms et les structures physiques sont faciles à concilier. La partie difficile est de trouver un équilibre. Vous ne voulez pas avoir un grand nombre d'assemblages plus petits. Je les regrouperai donc normalement à un niveau supérieur, puis le restructurerai lorsqu'il aura tendance à devenir trop grand ou si les sous-espaces de noms changent plus souvent que d'autres parties. .
Je le fais depuis des années et il est très confortable non seulement pour moi, mais également pour mes développeurs.
En ce qui concerne votre question EventArgs, je suis d’accord avec le consensus selon lequel je fais normalement une classe par fichier, mais je ferai l’exception de placer une classe EventArgs avec une autre classe si elle est à usage unique. Pour les utilisations multiples, je les mets au point logique le plus élevé de l’assemblage, ce qui permet à la structure d’espace de nommage de lier mon périmètre.
Autres conseils
J'aime généralement m'en tenir à la règle 1 class, 1 file, mais en ce qui concerne EventArgs, j'aime bien les déclarer dans le même fichier que celui que j'ai défini pour le délégué ou l'événement. À moins que les arguments ne soient utilisés par plus d’une hiérarchie de classes, ce qui m’arrive rarement. "/ />
En ce qui concerne le cache, je mettrais dans le dossier des classes dans lesquelles il prend en charge.
Même si j'aime une bonne organisation, on peut être trop anal avec.
C’est surtout un goût personnel.
Je suis d'accord avec ce que Brian Genisio a déclaré concernant l'emplacement des classes EventArg, etc.: si seulement utilisez-les une fois, mettez-les dans le même fichier où vous les utilisez. Pour les classes / fichiers généraux, j'ai toujours un dossier 'Général' (pratique!; -))
En ce qui concerne la structure des dossiers: je choisirais le second, celui-ci est à 3 niveaux ET maintient les sous-systèmes séparés. Win-Win!
Je veux juste ajouter un commentaire sur les noms. Je pense que le mot business mène à une mauvaise utilisation. Nous l’avons fait et nous ne savons pas de quoi il s’agit: logique de domaine ou couche de services. Je suggérerais des noms comme Domaine. Domain.Impl (pour séparer les interfaces d'Impl) et ensuite Services ... et peut-être Persistence si vous utilisez ORM ... cela peut être différent si vous utilisez une approche différente, mais pour être honnête, les noms BusinessLogic, DataAccess et BusinessObjects me rendent confus. Je ne comprends pas ce qui est quoi. BusinessObjects doit contenir une logique métier, logique? Ou sont-ils simplement des DTO? Alors pourquoi sont-ils dans un projet distinct de DataAccess?
