Non classé

Il y a 15 ans -

Temps de lecture 4 minutes

Configuration en Annotations Java ou en XML ?

L’arrivée de Guice dans le monde des frameworks de dependency injection a entraîné pas mal de questionnements. Je n’échappe pas à la règle !

Google a adopté dans Guice la configuration tout en Java : tout ce fait à base d’annotations et de l’API. De fait, il n’y a plus de fichier de configuration XML.

C’est encore un des reproches que l’on entend sur Spring : on déporte beaucoup de choses dans un fichier XML qui ne compile pas et pour lequel on n’est pas assisté.

Dans le même ordre d’idée, Les nouvelles annotations créées avec JPA (Java Persistence API) changent aussi notre façon de configurer Hibernate. Avant, on configurait tout dans le bon vieux hibernate.cfg.xml, maintenant on a la possibilité de le faire avec les annotations.

Maintenant que nous avons le choix : quelle solution doit-on préférer ? Java ou XML ?

Configuration en Java (API + Annotations)

Pour

  • Compilation (vérification des liens et de l’existence des classes par le compilateur)
Ceci permet de limiter les mauvaises configurations (ou plutôt de s’en rendre compte avant d’être obligé de tester) mais aussi de garantir la cohérence du modèle objet (implémentation, héritage, etc). Si on injecte une classe incompatible avec le type attendu, la compilation nous le signifie rapidement.
  • Code-completion
L’approche Java permet de réduire les risques de faute de frappe : les IDE nous assiste dans l’écriture du code. On atteint un certain niveau de productivité.
  • Simplicité et concision (par rapport au XML)
Le fait de positionner l’annotation directement dans la classe concernée, nous évite de devoir décrire la classe dans le fichier XML, pour que le framework qui analyse le fichier ait toutes les informations pour effectuer son traitement.
  • Refactoring simple
Nous sommes dans le monde Java, dans un IDE, il est plus simple de faire du refactoring que dans un mode mixte Java / XML.

Contre

  • Tout changement entraîne une recompilation
Si je veux exposer mon service en WebService, je dois ajouter l’annotation @WebService par exemple dans le code et recompiler. Qui dit recompilation, dit tests de non-regression …
  • Configuration répartie dans le code
Imaginons que j’ai configuré tous mes services en Web Service. Dans chaque service, je trouve l’annotation @WebService par exemple.
Si, plus tard je veux finalement changer l’exposition de tous mes services vers une exposition RMI / IIOP, il faut que je parcours tout le code (avec les risques d’omission) pour remplacer l’annotation.

Configuration en XML

Pour

  • Souplesse : Permet d’effectuer des changements sans impact sur le code (et sans recompilation)
Exemple avec Spring :
Mes deux services communique en appel Java (intra JVM) et je veux maintenant qu’il communique en RMI.
Je n’ai qu’à modifier le fichier de configuration de Spring pour changer l’exposition du service et changer l’injection pour l’appelant.
  • Pas de couplage fort du code avec le framework
L’avantage de passer par un configuration XML, c’est qu’il n’apparaît pas (ou peu) de trace du framework utilisé dans mon code.
  • Configuration centralisée
Les changements se font à un seul endroit (au sens d’un seul fichier ou d’un seul répertoire qui contient l’ensemble des fichiers de configuration).

Contre

  • Perte de lisibilité
Puisque les dépendances sont définies à part dans un fichier XML, ceci nous oblige à passer du code Java à XML mais sans assistance (sauf la fonction « rechercher » de l’éditeur) : ici, pas de Ctrl+Click pour naviguer dans les éléments.
  • Source d’erreur
Il n’y a pas de validation sémantique du XML (vérification de l’existence des classes, de la validité des assignations de type, etc). Avec notre fichier XML, ce n’est qu’au moment du test de l’application (runtime) que l’on sait si la configuration est bonne. On n’ignore pas qu’on est parti pour une petite session d’arrêts / modifications / relances.
Lourdeur et perte de productivité (beaucoup de choses à écrire en XML)
Il n’y a pas ou peu d’assistance à l’écriture du XML, notamment quand on doit renseigner des références à des éléments du source Java (noms de classe Java, de méthodes, etc).
  • Refactoring manuel (Search & Replace)
Le refactoring ne peut se faire qu’avec le concours de la fonction « remplacer » de l’éditeur, avec les risques d’erreur que cela entraine.

En synthèse

Configuration en Java Configuration en XML
Les plus
  • Compilation
  • Productivité
  • Indépendance du code et du framework
  • Configuration centralisée
Les moins
  • Couplage fort
  • Pollution du code
  • Lisibilité
  • Validation runtime

Published by

Publié par Publicis Sapient Engineering

Commentaire

2 réponses pour " Configuration en Annotations Java ou en XML ? "

  1. Published by Benoit Moussaud , Il y a 15 ans

    Spring a réagit très vite : le projet Spring JavaConfig [http://springframework.org/javaconfig] va bientot sortir en version 1.0, la version 1.0M2 est déjà disponible [http://www.springframework.org/node/455]

  2. Published by Hassan ZARYOH , Il y a 13 ans

    Un mixte des deux me semble un bon compromis. Notamment dans le cas de Spring. Annotations pour les données statiques, fichier XML pour les données plus dynamiques. Si on a besoin de changer l’implémentation, mieux vaut utiliser les fichiers XML que les annotations @Service … Enfin les outils type Spring IDE apportent une aide précieuse à l’écriture des fichiers XML

Comments are closed.

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.

REJOIGNEZ-NOUS