[SUGF] Spring Dependency Injection Styles - 10 juin 2010

J’étais, jeudi dernier, présent à la soirée organisée par le SUGF (Spring User Group France). Le sujet du jour, animé par Chris Beams, traitait des différentes manières d’utiliser les DI (Dependency Injection) via le framework Spring. Aucune nouveauté donc, mais néanmoins un solide rappel de quelques notions basiques de DI, qui pouvaient intéresser les néophytes comme les plus "anciens".

Voilà donc un résumé de cette soirée, qui m’a un peu rafraichi la mémoire, et fait découvrir une ou deux fonctionnalités que je ne connaissais pas encore.

A propos de Chris Beams

Chris Beams est ingénieur de développements sénior chez Spring source (maintenant VmWare), et fait donc partie de la poignée de commiters de Spring Core et de quelques autres Spring modules. Responsable de plusieurs évolutions majeurs de Spring 3.0, Chris Beams passe une grande partie de son temps à former des ingénieurs aux produits Spring, et à enseigner les bonnes pratiques de développement à adopter pour leur utilisation.

Bref, on peut dire qu’il sait de quoi il parle !

La conférence

Mon but n’est pas ici de vous retranscrire la conférence dans son ensemble, ou de vous proposer un "fil rouge" pour comprendre les DI, mais plutôt de résumer cette présentation forte intéressante. D’ailleurs, les slides utilisés seront bientôt mis à disposition par le SUGF.

Pour commencer, je vous conseille de lire cet excellent article d’Antoine Sabot-Durand, parlant de Spring en général, et de son évolution au fil des années et des nouvelles technologies. Bien que peu important pour la suite de mon post, je pense qu’il est toujours bien venu de connaitre un peu l’historique des technologies que nous aimons, et/ou utilisons tous les jours.

Pour en revenir à la conférence en elle même, elle a durée environ 2h, sur un rythme assez confortable. Une fois Chris Beams présenté, et quelques rappels sur Spring et les DI, nous voilà dans le vif du sujet. Dans la première partie, nous avons vu les différentes propriétés des DI : explicite ou implicite, interne ou externe, portabilité, type-safety, etc. Dans vos développements, le choix du type de DI à utiliser dépendra des critères que vous voulez valider. Par exemple, si vous voulez que votre code soit totalement portable, vous devrez utiliser la configuration XML au lieu des annotations (ces dernières impliquant l’import de package spécifique Spring). Bien que la JSR 330 – DI in Java – fournisse maintenant quelques annotations de base pour la DI, Spring peut aller beaucoup plus loin (configurer des paramètres à partir d’un fichier de properties par exemple, via l’annotation @Value), et l’on se retrouve rapidement à devoir importer des classes non portables.

La seconde partie de la présentation consistait à voir, à travers un exemple concret, toutes les possibilités mises à disposition par Spring pour effectuer la DI nécessaire au bon fonctionnement de votre application. On y trouvait par exemple la simple balise , la balise <namespace:* /> (ok, ce n’est pas de la DI à proprement parler, mais cela permet de la simplifier très fortement), ainsi que des différentes annotations (@Component – et ses "sous annotations" @Service, @Repository, etc. -, @Autowired, @Configuration, etc.). On peut donc classer ces méthodes de DI en 3 catégories : Injection via XML, injection via annotations, et injection via configuration. Chacune de ces méthodes a ses avantages et inconvénients, mais aussi ses limitations (par exemple, il est assez compliqué de configurer une classe venant d’une API externe à l’aide d’une classe de configuration Spring).

Ce qu’il faut retenir

Connaissant le Pour et le Contre de chaque manière de procéder, on peut développer ses applications de manière plus robuste, plus compréhensibles, ou plus portables. Cependant, il faut bien garder à l’esprit qu’il n’est possible de "faire plaisir à tout le monde", et donc, il n’existe pas (encore ?) de méthode universelle, 100% effective et sans défauts pour la DI. Quelque soit le type de projet, il faut isoler les paramètres les plus importants (performances ?, portabilité ?, intrusion dans le code ?, etc.), et utiliser les outils les plus appropriés, tout en sachant que l’on sacrifiera forcement une ou plusieurs caractéristiques. Une bonne utilisation de Spring permet de minimiser ces impacts, et l’on peut même utiliser plusieurs méthodes à la fois !

D’un point de vue plus personnel, mon impression est que Spring propose une multitude (ok, j’exagère un peu, plusieurs) méthodes de DI, qui permettent de répondre à la grande majorité (je ne me risquerais pas à dire la totalité, même si aucun de ces cas ne me viens à l’esprit pour le moment) des besoins de leurs utilisateurs. Cependant, cela laisse à l’utilisateur non expérimenté une liberté à mon sens un peu trop grande, et il devient assez facile de faire des erreurs ayant un impact direct sur les performances de l’application, ou bien sur son architecture. Pour résumer, Spring c’est bien, mais à consommer avec attention. L’aspect relativement simple des annotations (Spring 2.5+), par exemple, cache bien souvent une magie assez complexe qu’il est possible de mal connaitre et interpréter.