Episode 9: Mathias découvre MEF

Après cette petite pause sur COM la dernière fois, revenons sur le sujet des clients lourds et de la "composition".

Je vous ai déjà BEAUCOUP parlé de l’IDE Java Eclipse et la richesse de son framework de plugins basé sur OSGI.

Je vous ai parlé de .Net qui rattrape son retard à l’aide d’IOC et de MVVM.

Mais je ne vous ai pas encore parlé de VisualStudio.
Ce dernier offre depuis la version 2008 un noyau indépendant de l’IDE pouvant être utilisé pour n’importe quel type d’application : VisualStudio Shell.

Cella est possible à l’aide d’une gestion de « plugins » comme Eclipse (appelé « add-in »).
La gestion des add-ins de VisualStudio s’appuie sur COM (voila pourquoi il fallait que j’en parle avant ;) ).
Cela n’est pas étonnant puisque c’est LA technologie de communication inter-processus sur Windows.

Mais récemment, Microsoft a travaillé sur une nouvelle technologie d’activation de service et de "gestion de dépendances" et cette fois-ci 100% .Net. Cette dernière a été utilisée dans VisualStudio, afin de ne charger en mémoire que les add-in nécessaire suivant le besoin.

Cette technologie s’appelle MEF : Managed Extensibility Framework.
Et MEF fait du bruit : il est inclus officiellement dans .Net 4.0, Mono l’inclut dans la version 2.8 (car MEF est OpenSource, BRAVO Microsoft), et MEF est annoncé comme « remplaçant de l’IOC ».
En fait, même si on déclare des dépendances, ce n’est pas une solution IOC/DI…
D’ailleurs, je n’ai eu que de mauvais écho sur son sujet: mauvais usage, trop jeune?

Ce qui est bon à prendre, c’est l’aspect "attributs" pour déclarer ce qui serait visible à l’extérieur ou dans le conteneur IOC. Cela fait aussi pensé à la JSR-299 qui propose des annotations standards en Java pour tout type de conteneur IOC.

J’ai aussi exploré d’autres pistes pour une gestion de "plugin": Mono.Addin. Je trouve le principe très bien, et très inspirant, mais peut-être trop spécifique à ce pourquoi il a été inventé, cad, la gestion d’add-in dans Monodevelop.
Cette solution s’appuie aussi sur les attributs pour déclarer les Addins, donc c’est une bonne voie à suivre.

Episode 7 : Mathias découvre Unity+WPF+MVVM aux Techdays 2010

Je vous ai parlé de ma découverte de .Net dans l’épisode 6.
J’ai constaté un gros contraste avec Java: j’avais l’impression que Java était compliqué (EJB et tout ça) et que .Net était simple.

Cette simplicité n’est pas toujours positive, on peut même dire que Microsoft est "maudit" par ce fléau: rester attractif pour les développeurs débutants.

En général, cela donne des frameworks "sales" avec un fort couplage du code métier avec les interfaces, impossible à tester unitairement bien sûr.

Pour pouvoir découpler tout cela, on distingue 3 couches:

  • L’interface, appelée "view" ou "presenter", c’est le moyen d’afficher l’information
  • La logique métier, appelée "model", c’est ce que l’on va pouvoir tester à l’aide de tests unitaires
  • Les actions ou commandes, qui représente une action de l’interface par l’utilisateur qui va déclencher un traitement

Mais quand on sépare les responsabilités en plusieurs objets, on se retrouve avec un nouveau problème : comment coupler les vues, contrôleurs, etc. ? Comment "broker" les actions ?

Il y a une solution à cela: l’IOC. On peut dire aussi que le Databinding en est une autre.
Si Microsoft avait un train de retard sur les Framework IOC, ils connaissaient néanmoins déjà le problème depuis un moment, puisqu’ils l’avaient en partie résolu dans CAB.
C’est donc sans surprise que Microsoft nous livre son framework d’IOC "officiel" basé sur l’existant de CAB : Unity.

A la sortie d’Unity, j’étais déjà tellement convaincu par Spring.net que je n’ai jamais adopté le framework de Microsoft. De plus, les alternatives OpenSources étaient  bien présentes: Castle Windsor, Ninject, Autofac, etc.

A noter que les framework tel que CAB/RCP rendent vos clients lourds "extensibles", ce qui veut dire qu’un plugin va pouvoir greffer de "vues" dans l’interface, et s’abonner aux "commandes": chose tout à fait faisable avec de l’IOC.

Mais les frameworks IOC ne font pas tout, et ne suffisent pas à fournir une véritable architecture MVC pour client lourd, même s’ils peuvent nous y aider (voir mon poste précédent).

Pour résoudre le fléau du couplage fort entre l’interface et le code métier, Microsoft a sortie quelque chose de révolutionnaire: WPF et Silverlight!
Avec la venue de WPF et Silverlight, la communauté .Net OpenSource a commencé à se pencher alors sur le problème du MVC pour les applications lourdes. Divers frameworks apparaissent alors, comme Prism: http://compositewpf.codeplex.com/

Mais le MVC, comme on le connait dans le monde Web, ne s’applique pas bien aux clients lourds, surtout si on veut exploiter le Databinding et les événements.

Très franchement, je ne me suis jamais vraiment passionné pour WPF/Prism/etc. mais je voyais bien que quelque chose de gros était en train de venir…
J’ai ensuite assisté aux Techdays 2010 et j’en ai profité pour me mettre à jours sur le sujet.
Les sessions étaient d’ailleurs très accès sur Silverlight/WPF mais aussi sur le nouveau modèle MVVM (Model-View-ViewModel), et avec une bonne dose d’Unity bien sûr…
J’ai alors été très agréablement surpris par ces présentations, surtout celle qui montre comment supprimer tout le « code behind » des interfaces XAML avec des ViewModel et des Commands.

Pour mieux comprendre de quoi je parle, aller voir vite le screencast ici!!!

Bref, je ne sais pas si vous me suivez, mais l’IOC, le RCP, le MVC, la gestion de plugins, tout ça c’est intimement lié !

Petit à petit, .Net rattrape le retard vis-à-vis d’Eclipse RCP !
On peut même dire que .Net a pris de l’avance avec Silverlight/WPF, puisque la rédaction des interfaces en XML n’est qu’au stade de proposition pour Eclipse 4: http://wiki.eclipse.org/images/a/ab/XWT.pdf

GUICE : un framework de DI pour Java

Je pense que la Dependency Injection est une valeur fondamentale à l’écriture d’un programme, et je l’utilise tous les jours.
Je suis un adorateur (voir expert) de Spring/Spring.Net, et j’affectionne l’écriture de la structure du programme en XML.

Mais cette technique est très largement contestée :

  • nécessite un éditeur XML "intelligent" (ce qui est le cas grâce à SpringIDE) pour la complétion de la structure mais aussi des types.
  • interprétation au Runtime, et donc erreurs potentielles découvertes qu’au dernier moment.
  • verbeux
  • mauvaises performance (lecture du XML…)

Ça a aussi ses avantages, c’est pour ça que je reste adorateur de Spring, mais ce n’est pas le sujet…

J’ai déjà souvent eu ce débat avec Romain dans le monde .Net (voir http://ninject.org).
Je connais très mal les alternatives à Spring dans le monde Java, mais je connais celle de Google : Guice.

Voici un tuto/introduction très convaincante.

Pour ceux qui ne connaissent pas Ninject ou Guice, voici un peu le principe :
Au lieu de rédiger un XML, on utilise massivement les annotations (attributs en .Net) pour spécifier les injections. Ceci est aussi possible en Spring (technique dite Autowire) mais l’utilisation du XML reste nécessaire pour personnaliser plus finement les dépendances entre instances.
Dans le cas de Guice, au lieu de rédiger un XML, on créer une classe Module qui réalise le mapping entre une interface et la classe concrète à instancier/injecter.
On peut spécifier bien plus de chose que cela, mais je vous laisse lire l’article pour découvrir par vous même.

Pour ceux qui veulent suivre le débat "Spring vs Guice" ou "XML vs Code", voici le point de vue de la documentation officielle de Guice.

Suivre

Recevez les nouvelles publications par mail.