Est-ce que Spring ce n'est pas un peu: développer en XML au lieu de développer en Java?

Bonjour,

J'ai participé pendant quelques mois à un projet en Spring 3.0 et j'ai voulu approfondir. J'ai acquis le livre "Spring par la pratique" et j'ai lu ses premiers chapitres sur l'inversion de contrôle et le container léger.
Je me souviens que mon équipe avait beaucoup utilisé l'auto-wiring et la détection automatique pour avoir un fichier contexte plus réduit. Mais à la longue, bien que je n'étais pas assez expérimenté pour en comprendre les raisons, l'avait regretté un peu.

Le livre suggère la déclaration individuelle des objets mis à disposition par le container dans le fichier de contexte. De nombreuses déclarations sont décrites, et quelques balises ne doivent pas être oubliées.
En vérité, je commence à m'inquiéter. Avec Spring et cette approche, ne vais-je pas remplacer de la programmation et du déboggage Java par de la déclaration et du déboggage XML? Car l'ensemble de l'XML à produire me semble assez important, et il me rappelle les riches heures de JEE 1.3 où l'on en écrivait tout autant en descripteurs de toutes sortes et fichiers xml auxiliaires, qu'en Java proprement dit, pour notre plus grande difficulté.

Et pardon de poser le problème ainsi, parce qu'en fait je ne veux pas débuter la moindre polémique mais seulement observer à quel hauteur mon interprétation est fausse, mais: là où JEE 6 a réduit quasiment à néant l'emploi de descripteurs XML par l'usage d'annotations paramétrées (et je gage qu'il s'est lourdement inspiré de Spring pour y parvenir), Spring lui n'y est pas parvenu?

J'ai l'impression (mais peut être que je me trompe?) que des annotations auraient pu suffire à bien des endroits pour épargner des déclarations XML.

Pourquoi XML est-il si prégnant dans Spring?
La gestion des objets mis à disposition par le conteneur léger ne peut vraiment pas s'en passer?

En vous remerciant,

Grunt.

Mais en fait tu peux utiliser 3 modes de configuration dans Spring (et les combiner d'ailleurs) :

- XML (le plus connu peut être)
- Annotations
- API

C'est vrai que l'on parle peut être beaucoup de la config XML mais les annotations restent possibles.
Maintenant c'est vrai que si tu oublies de la config, c'est au démarrage que tu vois les problèmes mais même quand on fait l'équivalent en Java pur (avec ou sans Spring) on retrouve aussi ces problèmes (des null qui se trimbalent). La log Spring est d'ailleurs bien faite pour détecter les problèmes de config au démarrage (config XML ou pas)

Merci!
Je poursuis en ce moment dans Spring AOP, où je vois que l'on peut marquer son aspect d'une annotation @Aspect, mais que pour autant, il faut tout de même déclarer un (ou plusieurs?) tags <aop-aspectj-autoproxy /> dans le contexte.

Spring ne s'introspecte pas tout seul pour découvrir l'annotation @Aspect dans les classes pour y réagir comme il faut? Pourquoi ces indications XML supplémentaires sont-elles nécessaires? À quoi servent-elles?
Je n'arrive pas à faire à faire pendant de cette directive XML avec l'AspectJ que je connais.


Par ailleurs, Pour l'AOP sous Spring, qu'est qui est le plus sain? Déclarations en XML ou par annotations?

Citation:

---

Envoyé par grunt2000

Merci!
Par ailleurs, Pour l'AOP sous Spring, qu'est qui est le plus sain? Déclarations en XML ou par annotations?

---

De manière générale dans Spring, il y a des débats pour l'utilisation de la configuration via les annotations vs via XML. Je ne dirais pas qu'il y a une approche plus saine...

La configuration XMl va permettre de concentrer ta configuration dans des fichiers XMl et ainsi d'avoir une vue centralisée de ta configuration. A contrario, les annotations créées des dépendances de ton code "metier" au framework Spring... mais bon, ça peut éventuellement être acceptable. Les annotations peuvent également simplifier la configuration (mais vont nécessité une recompilation en cas de changement de config)

Bref, les deux ont leurs avantages... il faut seulement éviter de mixer trop fortement les deux car cela peut alors amener de la confusion.