comment réaliser un vrai couplage lâche à l'aide de Prism et Unity

Question

J'ai développé une application WPF utilisant les frameworks Prism et Unity et je suis inquiet de savoir si je les ai implémentés correctement ou non.

• classes abstraites/interfaces - j'ai organisé des interfaces pour toutes les couches dans un ensemble et ensuite référencé dans la bibliothèque respective pour la mise en œuvre. Maintenant, la bibliothèque référencée a accès à toutes les interfaces non requises des autres couches. Par exemple la couche de service a accès aux interfaces UI. Est-ce la bonne mise en œuvre en termes de clear separation ou devrais-je le diviser en plusieurs assemblages.

• Afficher les dépendances du modèle - J'ai utilisé EventAggregator principalement pour communiquer entre les modèles de vue. Dans certains cas, je passe l'instance d'autres modèles de vue directement dans le constructeur et la résous en utilisant le conteneur DI. Je veux omettre la dépendance de modèle de vue directe en introduisant l'interface pour réaliser la séparation claire. Comment puis-je organiser l'interface pour les modèles de vue dans un ensemble distinct de manière à ce que les autres développeurs puissent comprendre. Pour éviter de créer plusieurs projets d'interface utilisateur, j'ai créé un seul ensemble et les ai logiquement séparés en dossiers.

• Résumé Classe de module - Au lieu de spécifier toutes les dépendances du fichier bootstrapper.cs, je les ai factorisées dans le module correspondant. La plupart de mes projets lib de classe a des références aux bibliothèques Prism. Ainsi, les espaces de noms spécifiques à l'interface utilisateur sont ajoutés à des projets connexes non UI. Y a-t-il une meilleure approche pour y parvenir?

Answer 1

classes abstraites/Interfaces

Je vais exactement autant de "ensembles d'interface" si nécessaire, un trop grand nombre d'entre eux fait mal. Exemple: si a besoin de pour empêcher la couche 1 de communiquer potentiellement avec la couche 3, placez la couche 1-to-layer 2-interfaces dans un assemblage et celles de la couche 2-to-layer 3 dans une autre.

Voir dépendances modèles

Normalement, vous ne devriez pas besoin de passer des modèles de vue autour du tout. Faites circuler les données (modèle a.k.a.), les modèles de vue eux-mêmes ne contiennent pas de données indisponibles ailleurs ou précieuses pour quiconque à l'exception de la vue liée au modèle de vue.

Résumé Module de classe

Votre application prisme références prisme ... alors quoi? Tant que seules les implémentations IModule reçoivent le IUnityContainer, je ne m'en soucierais pas du tout. Si quelqu'un a besoin de publier un événement, il obtient le IEventAggregator ... C'est déjà une interface, et vous pouvez injecter un faux dans vos tests, donc pas besoin de plus d'abstraction.