Soirée du WSUG sur l’injection de dépendances

Mercredi 18 Décembre, la seconde soirée du WSUG (Wider Spring User Group) qui est un fork du Spring User Group (inactif) sur le thème de “L’injection de dépendance”  (en dehors de Spring et/ou en dehors de Java).
Ce User Group se revendique pluriel, indépendant, communautaire et technique.

Les sujets peuvent être proposés par les membres du groupe et porteront sur les technologies de l’écosystème Pivotal (telles que Spring Roo, Spring Boot …) dont font aussi partie Cloud Foundry et les solutions Big Data (Pivotal HD).

DI with Dagger via Hangout de Jesse Wilson @jessewilson | Square

Son curriculum est plutôt je trouve impressionnant (avis personnel d’un très jeune développeur).

  

Le framework Dagger est un fork de Guice. La motivation du développement de ce framework est de compenser les lacunes du framework Guice sur Android (performances, mémoire, démarrage).  Ainsi le slogan Dagger est « like Guice, but with speed instead of features ».

Dans l’univers Java les choix possible à la genèse du projet étaient nombreux javax.inject, Guice, Pico Container, Spring …

Les caractéristiques sont l’uniformité, et aussi découpler le concret du concret. Quelques fonctionnalités pertinentes de Dagger sont les Modules overrides et Multibindings (plugin architecture friendly), Lazy Loading …

 Les annotations principales de Dagger sont @Inject (dépendance à Injecter) et @Produces (dépendance qui satisfait).

 Dagger est un système de graphes. Il y a 2 étapes de validation : une à la compilation grâce à dagger-compiler qui vérifie que chaque annotation permet aussi notamment de générer un graphe des dépendances ; une autre lors du runtime (une sous étape de génération de code à partir du code source).

 Les plateformes compatibles sont HotSpot, Android, GWT (l’un des forks de Thomas Broyer ici)

 Support présentation Dagger

Di en Clojure par Claude Falguiere @cfalguiere | Valtech

J’ai découvert l’existence de ce langage lors de cette soirée. C’est un langage de programmation fonctionnelle (c’est un dialecte de Lisp orienté vers la programmation concurrente).

Claude Falguiere a insisté sur le fait qu’il n’y a pas réellement de notion d’Injection de Dépendances compte-tenu de la nature de ce langage.

On en ressent le besoin notamment lors de l’écriture des tests unitaires (les mocks). Pour satisfaire ce besoin il existe des méthodes alternatives :

  • liaison dynamique : par exemple redirection de la sortie standard vers une fonction
  • fonctions d’ordre supérieure : c’est une forme d’injection de dépendance en passant d’autres fonctions en paramètre
  • configuration des données

Ces techniques sont propres au langage. L’utilisation d’un framework spécifique de DI n’est donc pas si nécessaire …

Cependant quelques frameworks ont été cité lors de la présentation.

 Support sources github  lien

 Di en .NET par Anthyme Caillard @anthyme | Novedia

Son propos s’est illustré autour des concepts Ioc en environnement .NET

Trois frameworks ont été retenus pour illustrer ces concepts : Unity, MEF et Castle Windsor

Anthyme a illustré les fonctionnalités et leur mise en oeuvre à travers différents patterns :

  • Web request lifetime : une instance d’une dépendance donnée est réutilisé pour la même requête Web (l’équivalent du scope request qu’on connait de Spring)
  • Unit of Work : la dépendance résolue est partagée par tous les objets la déclarant, le tout dans un contexte d’exécution élimité (exemple : transaction).
  • Register by Convention et Fluent API : les dépendances sont chargées dans un registre avec une syntaxe permettant de manière élégante de qualifier les composants à charger.

Le live code utilisé lors la démo est disponible ici.

La présentation est disponible ici.

DI avec CDI par Antonio Goncalves @agoncal | indépendant

Après nous avoir décrit l’histoire de CDI (dont entre autres les différentes JSR, les oppositions entre contributeurs), il l’a illustré par l’utilisation de l’annotation @Inject et la notion de qualifier pour résoudre un conflit lorsque plusieurs dépendances sont disponibles.

Quelques annotations introduites par la spécification CDI :

  • @Inject
  • @Produces >> décrit l’implémentation qui satisfait la dépendance déclarée via @Inject
  • @Default
  • @Named
  • @Any

Pour utiliser la fonctionnalité du Lazy Loading on peut utiliser la classe “Instance” paramétrée par le type du composant réel. Il y a une utilisation systématique du pattern Proxy pour la résolution des dépendances (Antonio a d’ailleurs souligné que le terme Proxy apparaissait de nombreuses fois dans la spécification … qui n’est pourtant pas censée donner des détails d’implémentation).

Utilisable en standalone mais à condition d’utiliser une des implémentations de la spécification, ce qui peut s’avérer fastidieux. La norme CDI est disponible à partir de JEE 6 . Les principales implémentations existantes sont Weld (implémentation de référence), OpenWebBeans, CanDI.

La présentation est disponible ici

 Ce qu’on peut retenir de la soirée 

Il est évident que depuis l’avènement de Spring, une réflexion globale a été engendré pour résoudre la notion d’Injection de dépendances. Des nouveaux cas d’usage (mobile) remettent en question l’architecture même de ces solutions (cf. Dagger).

Les solutions se multiplient pour chaque langage majeur. Cependant, bien qu’intéressantes, elles ont encore un long chemin avant d’être aussi populaires que Spring Core.

Enfin, une soirée sans la moindre ligne de XML, moins efficace et pertinent désormais pour répondre aux nouvelles exigences (lisibilité, validation à la compilation, pour n’en citer que deux).

 La suite

La prochaine soirée est prévue pour le 16 janvier dans les locaux de Valtech et portera sur RabbitMQ par Alvaro Videla, developer advocate chez Pivotal.

Pour rester informé :

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *