Message passant dans un framework de plug-in

Question

Tout d'abord, il y a un peu d'historique sur ce problème disponible sur mon blog :

• http://www.codebork.com/coding/2008/06/25/message-passing-a-plug-framework.html
• http://www.codebork.com/coding/2008/07/31/message-passing-2.html

Je suis conscient que les descriptions ne sont pas très claires, je vais donc essayer de résumer ce que je tente du mieux que je peux ici.L'application est un programme de finances personnelles.Des informations plus détaillées sur le cadre lui-même sont disponibles à la fin de cet article.

Il existe un certain nombre de types de plug-ins différents que le framework peut gérer (par exemple, comptes, exportation, reporting, etc.).Cependant, je me concentre sur une classe particulière de plug-ins, appelés plug-ins de données, car c'est cette classe qui me pose problème.J'ai une classe de plug-in de données pour les comptes, une pour les transactions, etc.

Je suis à mi-chemin d'une vaste refactorisation qui m'a laissé l'architecture suivante pour les plug-ins de données :

• L'objet plug-in de données (implémentant les métadonnées d'initialisation, d'installation et du plug-in) [implémente IDataPlugin<FactoryType>]
• L'objet de données (tel qu'un compte) [implémente, par exemple, IAccount]
• Une usine pour créer des instances de l'objet de données [implémente, par exemple, IAccountFactory]

Auparavant, l'objet de données et l'objet plug-in étaient combinés en un seul, mais cela signifiait qu'un nouveau plug-in de transaction devait être instancié pour chaque transaction enregistrée dans le compte, ce qui provoquait un certain nombre de problèmes.Malheureusement, cette refactorisation a interrompu la transmission de mon message.L'objet de données implémente INotifyPropertyChanged, et j'ai donc rencontré un nouveau problème, et je ne sais pas comment le contourner :l'objet plug-in enregistre les événements auprès du courtier de messages, mais ce sont les objets de données qui déclenchent réellement les événements.Cela signifie que le plug-in d'abonnement doit actuellement s'abonner à chaque compte créé, transaction, etc. ! Ce n’est clairement pas évolutif.

D'après ce que je peux dire pour le moment, j'ai deux solutions possibles :

1. Faites de l'objet plug-in de données un intermédiaire entre les objets de données et le courtier de messages, en regroupant éventuellement les notifications de modification par lots.Je n'aime pas cela car cela ajoute une autre couche de complexité au système de messagerie dont je pense que je devrais pouvoir me passer.
2. Supprimez l'implémentation actuelle basée sur les événements et utilisez quelque chose d'autre qui est plus facilement gérable (WCF en mémoire ?!).

Donc je suppose que je demande vraiment :

1. comment résoudrais-tu ce problème?
2. Selon vous, quelles solutions potentielles j’ai négligées ?
3. Mon approche est-elle même vaguement sur la bonne voie/raisonnable ?!:-)

Comme vous pourrez le constater d'après les dates des articles du blog, une variante de ce problème me préoccupe depuis assez longtemps maintenant !En tant que tel, toutes les réponses seront grandement appréciées.

Le contexte du cadre lui-même est le suivant :

Mon framework de plug-ins se compose de trois composants principaux :un courtier de plug-ins, un gestionnaire de préférences et un courtier de messages.Le courtier de plug-ins fait le travail de base du plug-in :découvrir et créer des plug-ins.Le gestionnaire de préférences gère les préférences utilisateur pour le framework et les plug-ins individuels, par exemple quels plug-ins sont activés, où les données doivent être enregistrées, etc.La communication s'effectue via publication/abonnement, avec le courtier de messages assis au milieu, rassemblant tous les types de messages publiés et gérant les abonnements.La publication/abonnement est actuellement implémentée via le .NET INotifyPropertyChanged interface, qui fournit un événement appelé PropertyChanged;le courtier de messages construit une liste de tous les plug-ins implémentant INotifyPropertyChanged et souscrit à d'autres plug-ins cet événement.Le but de la transmission du message est de permettre aux plug-ins de compte et de transaction d'informer les plug-ins de stockage que les données ont été modifiées afin qu'elles puissent être enregistrées.

Answer 1

Voici ma compréhension de votre question :Vous disposez d'un objet plugin qui devra peut-être écouter les événements sur x objets de données - vous ne souhaitez cependant pas vous abonner à l'événement sur chaque objet de données.Je suppose que plusieurs plugins voudront peut-être écouter des événements sur le même objet de données.

Vous pouvez créer un objet de type session.Chaque plugin écoute les événements sur l'objet de session.L'objet de données ne déclenche plus l'événement - il appelle l'objet de session pour déclencher l'événement (l'un des paramètres devrait être l'objet de données déclenchant l'événement).

Cela signifie que vos plugins ne doivent s'abonner qu'à un seul événement, mais qu'ils obtiennent l'événement de tous les objets de données.

D'un autre côté, si un seul plugin écoute un objet de données à la fois, pourquoi ne pas simplement demander à l'objet de données d'appeler directement le plugin ?

Answer 2

Ouah!Grande question !:)

Corrige moi si je me trompe.Votre solution de base est désormais une sorte de modèle d'observateur, dans lequel l'objet de données (compte, etc.) informe des changements dans leurs états.Vous pensez que le problème est que le plugin d'abonnement doit s'inscrire dans chaque objet pour pouvoir gérer les notifications.

Ce n'est pas un problème en soi, vous pouvez mettre le contrôle des événements dans le Modèle de domaine, mais je vous suggère de créer un Couche de service et effectuez ces notifications d'événements dans cette couche.De cette façon, un seul objet serait responsable de la publication des notifications.

Martin Fowler propose une série de modèles d'événements sur son blog. Vérifiez-le!Très bonne lecture.

Answer 3

Il est encore tôt, mais avez-vous envisagé d'essayer d'utiliser MEF au lieu de rouler le vôtre ?