Actuellement je construis une application utilisant le dernier prisme pour Silverlight 4. J'ai un module et dans ce module j'ai deux vues avec des modèles de vue. J'ai aussi une vue de module avec deux régions pour chaque vue. Lors de l'initialisation du module, je suis en train d'enregistrer mes vues et d'afficher les modèles dans le conteneur Unity et également d'enregistrer des vues avec les régions correspondantes. Le problème est que les vues doivent afficher quelque chose de similaire à l'information de table-détail - la première vue montre les entités disponibles et la deuxième vue montre le détail de l'entité sélectionnée.WPF/SL Implémentation d'Aggregator avec un comportement durable des abonnés?
J'ai besoin d'un moyen de leur passer l'entité sélectionnée initiale. La première vue nouvellement créée n'a aucune entité sélectionnée et la seconde vue nouvellement créée n'affiche aucun détail.
Actuellement, je le fais de cette façon: Dans le module, je crée deux modèles de vue et les enregistre comme des instances dans le conteneur Unity, puis j'enregistre les vues en tant que types pour les régions correspondantes. Chaque vue est abonnée à EntitySelectedEvent à partir de EventAggregator. L'initialiseur de module publie cet événement après l'initialisation et ainsi deux vues sélectionnent la même entité. Je sais que cela semble moche - J'ai essayé de publier cet événement à partir d'un des modèles de vue, mais le problème est que EventAggregator dans Prism ne prend pas en charge les abonnés durables - cela signifie que si le second modèle d'affichage n'était pas abonné à l'événement le premier modèle de vue a tiré, il ne recevra pas et l'événement. Je sais que c'est un comportement normal de EventAggregator, mais je cherche une solution quand les modèles de vue peuvent déclencher des événements sans dépendre de leur ordre d'initialisation - c'est le premier modèle qui peut déclencher l'événement avant la création du deuxième modèle et le second recevra cet événement «en file d'attente» après s'être abonné à lui.
Y a-t-il d'autres implémentations de messagerie pour WPF/SL qui supportent un tel comportement ou utilisent un médiateur (dans mon exemple c'est un module lui-même) n'est-ce pas une si mauvaise idée? Un gros problème avec médiateur est que les modèles doivent être créés immédiatement dans l'initialisation et qu'ils ne peuvent pas être enregistrés comme types dans le conteneur car cela conduit à nouveau à des abonnés manquants.
Merci, bonne astuce. Mais je ne veux pas de fuite liée à la logique (et la sélection est une vue liée dans mon cas) à mon modèle. Je ne veux pas continuer à sélectionner la logique dans les modèles de vue et relayer sur la messagerie basée sur les événements (au moins c'est la seule solution que je suis arrivé) - le problème est que pour relier les modèles de vue, je vais les créer dans un ordre spécial si un des modèles de vue publie un événement ou utilise un médiateur qui déclenchera un événement après avoir su que les modèles de vue ont été créés (mon médiateur qui est le module fait exactement cela). – sha1dy
Eh bien, je dirais que les événements dans Prism devraient être utilisés pour la communication inter-module. Par exemple. un vm dans le module A ne sait rien à propos de vm-s dans le module B, et s'en fout, donc il a déclenché un événement qui pourrait être intéressant pour quelqu'un et c'est tout. Mais si les deux vm-s vivent dans le même module, et surtout si leur fonctionnalité est si clairement couplée - pourquoi les empêcher de se connaître les uns les autres? Parent vm peut être simplement injecté dans l'enfant un. N'utilise-t-il pas des événements au lieu d'introduire un niveau de complexité inutile? –
Peut-être que vous avez raison - ils sont en effet dans un module et un module de vue en contrôle un autre. Je vais réfléchir à votre proposition. – sha1dy