| « Sortie de la release de GAT Février 2008 | Article sur les software factories » |
Extensibilité de l'Event Broker avec CAB
Pour ceux qui ont utilisé ou utilisent le framework CAB (Composite User Interface Application Block), l'un des premiers besoins qui se fait ressentir est de faire communiquer les différentes modules qu'on crée sans passer par un couplage fort.
Le design pattern Observateur (ou publish / subscribe) sur lequel repose la communication inter-modules est implémenté dans le mécanisme de l'Event Broker. Il permet donc de notifier à un module un événement vers d'autres modules sans pour autant les connaître.
L'un des défauts que j'ai rencontré est l'utilisation de la reflection dans ce mécanisme qui impacte la performance globale de l'application. Il est également obligatoire d’avoir la même signature et les mêmes types véhiculés du publieur à l’abonné ce qui demande une organisation sans faille entre les développeurs de différents modules.
On spécifie les noms des événements qu’on publie par des constantes ainsi que chez celui ou ceux qui y souscrivent. Aussi, il est intéressant de les centraliser pour éviter des erreurs de nommage des 2 côtés.
On arrive au final à un plat de spaghettis lorsqu’on a plusieurs modules qui s’appellent avec des interdépendances et des réactions en cascade à gérer.
La solution est d’utiliser une classe qui puisse agréger et permettre la gestion (routing et transformation) des événements des publieurs aux abonnés. Cela facilite également l’écriture des tests unitaires.
Jeremy D. Miller (sur son blog sur le site CodeBetter) nous expose sa solution avec l’utilisation de generics et l’implémentation du design pattern Event Aggregator (décrit ici sur le site de Martin Fowler). Il agit tel un Message Broker dans un hub et adresse la problématique de comment architecturer les messages.
Glenn Block (sur son blog du site CodeBetter) lui répond en expliquant le travail effectué actuellement pour la nouvelle version de CAB pour WPF dans l’amélioration du mécanisme de l’Event Broker.
Attendons de voir le résultat en sachant que CAB a été pensé et construit pour des applications Windows Forms alors que la gestion des événements en WPF est différente avec la notion des Routed Events.