Où devraient aller les fichiers de ressources et à quelle granularité (application/assembly/namespace/class/...)? En utilisant une architecture en couches, on peut diviser une application en deux ensembles dédiés distincts. Un avantage est qu'il est plus facile de gérer les dépendances et de s'assurer que le code ne soit pas entrelacé.Quelle est la meilleure stratégie pour regrouper des ressources dans une application .NET
Lors du refactoring à grande échelle, les pièces peuvent être divisées en assemblages séparés ou déplacées dans leur propre assemblage. Cela peut arriver parce que la fonctionnalité a suffisamment mûri pour être déplacée dans la couche principale ou est devenue suffisamment grande pour justifier son déplacement dans son propre assemblage.
Pendant le processus de refactoring, il se peut que la ressource doive être déplacée. Cela peut être plus ou moins difficile selon la stratégie utilisée pour regrouper les ressources et le type de refactoring en cours. Les ressources (chaînes, images, fichiers, etc ...) ont pu être groupées de plusieurs manières: - dans un seul fichier de ressources par assembly, - dans un fichier de ressources par espace de noms dans un assembly, - dans une ressource fichier pour chaque classe, - en un seul assemblage partagé par tous les assemblages de l'application, - etc.
Le refactoring est une opération qui pourrait être affectée par la stratégie de regroupement choisie pour les ressources. D'autres opérations, comme la traduction des chaînes dans les fichiers de ressources, seront également influencées. Quelle est la meilleure stratégie de regroupement et pourquoi?
Je n'aime pas l'idée d'un assemblage de ressources partagées. Vous pourriez vous retrouver avec un système souffrant d'une faible cohésion. Si je ne devais partager qu'un seul assemblage avec une autre application, je devrais envoyer toutes les autres ressources. Je suis enclin à favoriser le rapprochement. De cette façon, il est plus facile à gérer à l'avenir. – Christo