Discussion :

[phryos]

Bonjour tout le monde,
je travaille sur spring 3.0 et je me demandais s'il valait mieux passer par des annotations pour la déclaration des beans, transaction,... ou par des fichiers xml. Je suppose que c'est aussi long de prendre l'un ou l'autre en main, mais le xml me semble pour clair, ou plus maintenable que les annotations.
Je m'explique : l'avantage du fichier xml est de concentrer l'information à un seul endroit du projet au lieu de dispatcher les informations à droite à gauche dans la miriade de classes du projet. Du coup c'est peut être plus facile à maintenir plutôt que d'aller à la pèche au info lorsqu'il y a un problème.

Le but de ce post est de plutôt partager son avis sur la question et de bénéficier de retour d'expérience de personne ayant pu manipuler l'un ou l'autre.

[OButterlin]

Il y a surtout un avantage pour le xml quand on doit modifier le paramétrage en cours de route.
L'annotation est un paramétrage plus "static".

Un mixe des deux peut très bien se faire aussi...

[phryos]

Il me semble que les annotations permettent un paramétrage plus fin que la description xml. Ce qui m'inquiète, c'est si il y a du refactoring à faire...

Souvent les tutoriaux ne présentent que les solutions xml sauf dans le cas spécifique de spring mvc où c'est plutôt l'inverse. A noter que sur les transactions, cela semble plus intéressant de passer par les annotations que par le doc xml...

C'est peut être une vue de l'esprit un peu étroite, mais j'ai l'impression que ça met plus le bazar de faire des mixes au lieu de faire soit l'un soit l'autre entièrement (comprendre soit xml, soit annotation). C'est pour cela que je voulais prendre l'avis de tout le monde...

[Jimmy_]

Rien de pire pour la maintenance qu'une appli qui mélange les genres. Je prefaire avoir un truc homogène. On a vraiment pas le temps de chercher la plupart du temps.
La javadoc est aussi une ressource des plus importante pour la maintenance ne pas l'oublier.

[OButterlin]

Très discutable...
Rien de pire pour moi que le XM-Hell !
Tout ce qui est paramétrage statique devrait être mis sous forme d'annotations (paramétrage des transactions, etc...)

[Jimmy_]

Si la question est uniquement pour la maintenance, fait ce que tu veux du moment que tout est au même endroit, sous la même forme et correctement documenté.

Après la xml ou pas, c'est pour moi un autre débat.

[thebloodyman]

Pour améliorer la maintenance et d'évolutivité, je préfère 1000 fois les annotations + autowired au xml lorsqu'elles existent.
On n'a besoin de toucher qu'à un seul endroit lorsqu'on ajoute, modifie ou supprime un bean : la classe java.
Avec le xml, tu dois te palucher très souvent la classe java + xml... Risque d'erreurs et d'oublis augmentés... Je parle en connaissance de causes.

Ce que fais aujourd'hui : utiliser le xml dans Spring seulement quand l'équivalent en annotation n'existe pas (en général des beans de configuration : spring security, persistence, viewResolvers... et les trucs exotiques du genre aop proxy).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Il y a surtout un avantage pour le xml quand on doit modifier le paramétrage en cours de route.
L'annotation est un paramétrage plus static.

En cours de route ? Comment ? Puisque le contexte de Spring a déja été créé.
Tout comme avec les annotations, tu es obligé de redémarrer ton appli (soit ton serveur si tu fais du web), à moins d'utiliser des beans scripted, mais la c'est un autre débat...
Dans un cas, tu modifies une classe java, dans un autre du xml.

[OButterlin]

Avec la modification d'annotation, on a tout de même une classe recompilée, à la différence du xml.
En pratique, pour donner un exemple, définir des attributs transactionnels sur une méthode correspond à un paramétrage "static", alors que l'inversion de contrôle est plus dynamique. On peut utiliser telle implémentation d'une classe pour telle DB ou une autre en fonction des besoins client ou de fait qu'on est en phase test ou en exploitation.

Ce n'était pas pour moi ce que tu qualifies de "en cours de route"

[thebloodyman]

Je comprends ce que tu veux dire pour le paramétrage statique.
Mais la encore, c'est un choix de vouloir le mettre sous forme d'xml ou d'annotation.
Certes c'est censé être statique une configuration transactionnelle mais supprimer un service transactionnel n'est pas qqch d'impossible si on en a plus besoin.
Imaginons que tu supprimes un service transactionnellement configuré pour Spring dans le xml, tu es obligé de supprimer ses références spring dans le xml, sinon code mort voir erreur lors du chargement du contexte Spring.
En utilisant les annotations, quand tu supprimes la classe ou la méthode, tu effaces à la fois la classe ou la méthode mais aussi la définition Spring.

Exacte pour la recompilation de la classe.
Mais est-ce une charge si importante de recompiler une classe ?

Si si c'est pour toi mais sans aucune attaque personnelle

Il y a surtout un avantage pour le xml quand on doit modifier le paramétrage en cours de route.

Je disais que le terme 'en cours de route' n'était pas opportun pour qualifier le xml.
Je me répète mais dans les deux cas (annotation ou xml), une fois le contexte applicatif de beans spring chargé au démarage de l'application, une modification d'un bean que tu sois en annotation ou en xml nécessite le redémarrage de ton appli ou serveur pour recharger le contexte Spring.
Donc voila pourquoi je ne suis pas d'accord sur le terme 'en cours de route'.

[OButterlin]

Je disais que le terme 'en cours de route' n'était pas opportun pour qualifier le xml.
Je me répète mais dans les deux cas (annotation ou xml), une fois le contexte applicatif de beans spring chargé au démarage de l'application, une modification d'un bean que tu sois en annotation ou en xml nécessite le redémarrage de ton appli ou serveur pour recharger le contexte Spring.
Donc voila pourquoi je ne suis pas d'accord sur le terme 'en cours de route'.

Bien d'accord avec toi, l'expression était bien mal choisie
Je parlais du cycle de vie de l'application, pas de son exécution...

[phryos]

Pour améliorer la maintenance et d'évolutivité, je préfère 1000 fois les annotations + autowired au xml lorsqu'elles existent.

Est-ce que l'autowired n'est pas sujet à beaucoup de plantage? En faisant la lecture de spring par la pratique, il est fait mention que son emploi peut être problématique lorsque plusieurs implémentations candidates sont possibles et donc un risque d'injection incorrecte lors d'un démarrage de l'application...

Personnellement je trouve pas mal les annotations mais elles sont pas mal intrusive dans le code, ce qui est moins le cas de l'xml. Ce qui est séduisant dans le xml, c'est que toute la définition de l'application est sous les yeux. Par contre ça doit être effectivement plus problématique lors du développement de faire attention aux fautes de frappes, aux oublis de déclaration, que sais je encore... Ce qui ne doit pas être le cas de l'annotation, mais qui elle nécessite une meilleure connaissance du modèle objet de l'application. (par ex, essayer de deviner qu'elle est l'instanciation d'un objet autowired quand il n'y a qu'une interface donnée).

[thebloodyman]

Est-ce que l'autowired n'est pas sujet à beaucoup de plantage ?

Mon expérience sur différents projets avec et sans l'autowired m'a montré l'inverse.
Avec le xml, les gens (dont moi compris) oublient trop souvent de modifier toutes les déclarations xml impactés(surtout lors de la multiplication des fichiers xml), donc beaucoup de plantages lors du chargement du contexte Spring.
Je vais te donner un exemple très simple et courrant. Imaginons que tu as dans ton appli un bean Spring utilisé comme dépendance dans 5 autres beans Spring.
Si tu modifies le package de la classe d'implémentation du bean ou bien même que tu le supprimes, sans l'utilisation de l'autowired, tu vas devoir retrouver toutes les déclarations xml faisant références à ce bean dans ton appli (déclarations qui peuvent se trouvaient dans plusieurs fichiers mêmes)
D'où le risque d'oublis et de plantage.

En faisant la lecture de spring par la pratique, il est fait mention que son emploi peut être problématique lorsque plusieurs implémentations candidates sont possibles et donc un risque d'injection incorrecte lors d'un démarrage de l'application...

Il y a plusieurs manières d'autowired. A partir du moment ou on a plusieurs implémentations Spring pour une même interface, il est évident que l'autowired byType qui est utilisé par défaut est à proscrire.
L'autowiredByName devient alors salutaire, et aura peu de risque de créer un bug, alors de vouloir le créer volontairement
Concernant une injection incorrecte non détectée lors du chargement du contexte, je ne pense pas que cela est impossible mais c'est très rare.
Je n'en ai jamais vu personnellement depuis 3,5 ans d'xp avec Spring.
Les erreurs d'injections que j'ai rencontré ont toujours été détectées lors du chargement du contexte :
plus d'une classes candidate -> Exception

Après c'est comme pour toute technique : sans rigueur, risque d'erreur : valable pour l'écriture des beans en xml comme pour les annotations.
Après dans le cas des annotations, tu as moins à écrire.

Ce qui est séduisant dans le xml, c'est que toute la définition de l'application est sous les yeux.

Je pensais pareil avant. Mais quel est le but de Spring ? De documenter ton application ou de coder plus efficacement ?
Si c'est pour documenter, je préfère faire un doc d'archi générale et m'affranchir du xml. Je gagnerais largement en temps.

Par contre ça doit être effectivement plus problématique lors du développement de faire attention aux fautes de frappes, aux oublis de déclaration, que sais je encore.

Exact, j'ajouterais le cout plus couteux du refactoring. Avec le xml, tu as une double peine lors de modification d'un bean.

Ce qui ne doit pas être le cas de l'annotation, mais qui elle nécessite une meilleure connaissance du modèle objet de l'application.

Je suis tout à fait d'accord.
Mais avant de coder, je pense qu'il est normal d'être formé sur l'achi d'une application si on ne le connait pas.
C'est pas au xml de Spring de remplacer un doc de conception ou de la javadoc .

(par ex, essayer de deviner qu'elle est l'instanciation d'un objet autowired quand il n'y a qu'une interface donnée).

Merci eclipse dans ces cas la

[phryos]

Je suis tout à fait d'accord.
Mais avant de coder, je pense qu'il est normal d'être formé sur l'achi d'une application si on ne le connait pas.
C'est pas au xml de Spring de remplacer un doc de conception ou de la javadoc .

Je plussoie. C'est vrai que c'est un faux problème que j'ai posé. Une personne ne connaissant pas l'archi n'a rien à faire sur le projet. Disons que je pensais plutôt au cout d'entrée pour un nouvel arrivant...

(par ex, essayer de deviner qu'elle est l'instanciation d'un objet autowired quand il n'y a qu'une interface donnée).

Merci eclipse dans ces cas la

Tu as une astuce ?

En tout cas, merci beaucoup pour le retour d'expérience sur le sujet. Jusqu'à présent, j'ai vu plus d'exemple avec des descriptions xml qu'avec des annotations. Du coup je pensais que c'était plus préférable de faire avec. Mais comme certains exemples datent un peu aussi... Un peu difficile de se faire sa propre opinion...

[thebloodyman]

par ex, essayer de deviner qu'elle est l'instanciation d'un objet autowired quand il n'y a qu'une interface donnée.
...
Mais comme certains exemples datent un peu aussi... Un peu difficile de se faire sa propre opinion...

Tu voulais dire 'implémentation' et non 'instanciation', je crois.

Sous Eclipse, t'as plusieurs solutions dont :
- afficher la hiérarchie descendante du type (Ctrl + T lorsque le curseur est sur un type) si t'as le super type.
- faire une recherche de type (Ctrl + Shift + T) si tu sais le type que tu recherche.

Avec ces deux techniques, pas compliqué de connaitre l'implémentation des types autowired.
Si il y n'a qu'une implémentation de l'interface : un Ctrl + T et bingo
Si il y a plusieurs implémentations, c'est à peine plus dur
Comme dit précédemment, dans ce cas, l'autowired bytype n'est pas conseillé. On lui préfère l'autowired byname.

Dans ce cas, pour connaitre l'implémentation choisie : regarder la valeur du qualifier annotant la dépendance.

Petit exemple illustratif avec 1 interface et 2 implémentations.
InterfaceBean : l'interface
Bean et BeanBis : les implémentations.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
@Component("bean") 
// param 'bean' pour l'illustration et non obligatoire puisque par défaut l'id du // bean est le camelcase de la classe
public class Bean implements InterfaceBean
{
...
}
 
@Component
public class BeanBis implements InterfaceBean
{
...
@Autowired
@Qualifier("bean")
private InterfaceBean uneDependence;
...
}

Quand tu vois la dépendance uneDependence, tu sais tout de suite qu'elle est de type Bean et non BeanBis.

En espérant t'avoir éclairé avec un exemple concret annotation + autowired

[phryos]

Tu voulais dire 'implémentation' et non 'instanciation', je crois.

Les deux mon capitaine, quelle instance d'objet implémentant l'interface déclarée autowired (par type) est utilisée (Mais il me semble avoir lu que s'il y a plusieurs possibilités, une exception est générée par spring, d'où peut-être faux problème)
Dans mon dev, j'ai effectivement commencé à utiliser l'autowired par nom qui m'a semblé beaucoup moins "hasardeux".

Ton exemple est nickel pour comprendre le concept, merci beaucoup.

Sinon comme ça en passant, comment peut-on faire pour annoter avec autowired une méthode d'une classe parente. Sachant que la méthode parente est déclarée final.

[thebloodyman]

Je n'ai jamais rencontré le cas où j'avais besoin que méthode soit final.
Mais à priori, procéder de la même manière devrait fonctionner.

Le modifier final pose problème lorsque l'injection de la dépendance se fait de manière non standard : génération automatique de classe proxy par Spring. Problème car la méthode ne peut être redéfinie.

[phryos]

Merci à tous pour vos bons conseils

[DrHelmut]

Salut à tous,

je ré-ouvre le sujet car, sur mon projet actuel, nous avons avec un collègue un problème existentiel avec la conf spring.

Le contexte : un gros projet maven avec deux applis web, des webservices soap à exposer, d'autres à consommer, du spring batch, du hibernate/jpa...
Et en prime une grosse moulinette pour logguer toutes les méthodes publiques, via aop.

Initialement, j'avais conçu le bousin de telle façon que les définitions des beans spring soient dans des xml, groupés par "couche".
=> Déjà, par rapport à mon choix initial, je ne comprend pas les personnes qui décident de faire du full annotations "car le xml c'est mal" : pour moi, c'est du lobbying, il n'y a aucune vraie raison derrière cette phrase; les contextes spring en xml peuvent justement être séparés en plusieurs fichiers, facilement lisibles et compréhensibles, et importés dans une config globale. Ce qui est bien pratique dans le cadre d'un projet avec plein de modules maven.

Bref, à ce moment là, tout allait bien : on avait des config xml "cible", des configs spécifiques pour les TU, des configs "stubs"...

Et soudain, le drame : le "cp technique", plus habitué aux annotations, a cassé la configuration existante en remplaçant les définitions des beans par des annotations directement dans les classes, et en remplaçant du coup le contenu des xml par de simple "component-scan" sur mes packages contenant les beans...

Et c'est là ou j'aimerais partager un peu de notre retour d’expérience à ce sujet, car peut-être nous somme nous mal pris... Toujours est-il que, en gros, notre ressenti est que :

- les annotations empêchent de gérer facilement une conf spécifique aux tests. Dans notre cas, nous avions besoin de différencier tests unitaires et tests d'intégration, voire de faire des combinaisons de conf...
=> Bref, quoi qu'on en dise et je demande à ce qu'on me prouve le contraire, les configs xml permettent beaucoup plus de souplesse; (Comme il a été dit, les annotations devraient être limités aux éléments statiques)

- les annotations ont tendance à casser tout l'intêret de l'IoC : ce n'est pas à l'implémentation de dire "je suis tel bean" ou "tel attribut correspond à telle clé dans mon fichier de properties" ; faire ainsi reviens à peu de chose près à coder en dur ! Comment apeller mon bean dans une autre classe si je ne connais pas son nom ? Je dois lancer une recherche dans eclipse sur "@Service(monbean)" ? C'est abbérant ! Et si je change le nom de la clé du fichier de properties ?? Je dois là encore chercher dans le code les annotations qui utilisaient cette clé et la modifier... et on a tout cassé l’intérêt de l'IoC, le fait d'avoir les éléments dynamiques configurés en un seul point d'entrée, facilement lisible et adaptable...

Vos avis et retours d’expérience nous intéressent, merci d'avance.

[Targan]

Bonjour, ce sujet m'interesse particulièrement et j'aurais aimé avoir l'avis de certains d'entre vous.

Alors, annotation ou config XML ?

Pour des gens peu ou "moyennement" expérimentés sur ce framework (et aux annotations), n'est il pas plus simple de faire du XML ?

Pourquoi le XM-Hell comme certains le disent est il si désagréable à vos yeux ? (qqun bosse t il avec du SGML, le XML est topissime à côté ^_^)

Merci par avance pour vos retours.

[NicoL__]

XML-Hell car un fichier de context spring, ou plutôt pour une application un peu importante, DES fichiers context spring, cela peut vite devenir totalement impossible à maintenir et très complexe.
Du coup en pratique une modification à chaud de ces fichiers est impossible, au minimum il faut rejouer les tests unitaires...