Configuration XML contre configuration basée sur les annotations [fermé]

Dans quelques grands projets sur lesquels j'ai travaillé ces derniers temps, il semble devenir de plus en plus important de choisir l'un ou l'autre (XML ou annotation). À mesure que les projets se développent, la cohérence est très importante pour la maintenabilité.

Mes questions sont les suivantes: quels sont les avantages de la configuration basée sur XML par rapport à la configuration basée sur les annotations et quels sont les avantages de la configuration basée sur les annotations par rapport à la configuration basée sur XML?

Les annotations ont leur utilité, mais elles ne sont pas la solution miracle pour tuer la configuration XML. Je recommande de mélanger les deux!

Par exemple, si vous utilisez Spring, il est tout à fait intuitif d'utiliser XML pour la partie d'injection de dépendances de votre application. Cela éloigne les dépendances du code du code qui l'utilisera, en revanche, l'utilisation d'une sorte d'annotation dans le code qui a besoin des dépendances rend le code conscient de cette configuration automatique.

Cependant, au lieu d'utiliser XML pour la gestion transactionnelle, marquer une méthode comme transactionnelle avec une annotation est parfaitement logique, car il s'agit d'informations qu'un programmeur souhaiterait probablement connaître. Mais qu'une interface va être injectée en tant que sous-typeY au lieu d'un sous-typeX ne doit pas être incluse dans la classe, car si maintenant vous souhaitez injecter SubtypeX, vous devez changer votre code, alors que vous aviez un contrat d'interface avant de toute façon, donc avec XML, il vous suffit de modifier les mappages XML et c'est assez rapide et indolore de le faire.

Je n'ai pas utilisé les annotations JPA, donc je ne sais pas à quel point elles sont bonnes, mais je dirais que laisser le mappage des beans à la base de données en XML est également bon, car l'objet ne devrait pas se soucier de l'origine de ses informations. , il devrait juste se soucier de ce qu'il peut faire avec ses informations. Mais si vous aimez JPA (je n'ai aucune expérience avec lui), allez-y.

En général: si une annotation fournit des fonctionnalités et agit comme un commentaire en soi, et ne lie pas le code à un processus spécifique afin de fonctionner normalement sans cette annotation, optez pour les annotations. Par exemple, une méthode transactionnelle marquée comme étant transactionnelle ne tue pas sa logique de fonctionnement et sert également de bon commentaire au niveau du code. Sinon, ces informations sont probablement mieux exprimées en XML, car même si elles affecteront éventuellement le fonctionnement du code, elles ne changeront pas la fonctionnalité principale du code et n'appartiennent donc pas aux fichiers source.

Il y a ici un problème plus large, celui des méta-données externalisées vs intégrées. Si votre modèle d'objet ne persiste que d'une seule manière, les méta-données intégrées (c'est-à-dire les annotations) sont plus compactes et lisibles.

Si, cependant, votre modèle objet a été réutilisé dans différentes applications de telle sorte que chaque application souhaite conserver le modèle de différentes manières, alors l'externalisation des méta-données (c'est-à-dire des descripteurs XML) devient plus appropriée.

Ni l'un ni l'autre n'est meilleur, et donc les deux sont pris en charge, bien que les annotations soient plus à la mode. En conséquence, les nouveaux frameworks hair-on-fire comme JPA ont tendance à mettre davantage l'accent sur eux. Les API plus matures comme Hibernate natif offrent les deux, car on sait qu'aucune n'est suffisante.

Je considère toujours les annotations comme une sorte d'indicateur de ce dont une classe est capable, ou comment elle interagit avec les autres.

La configuration Spring XML, pour moi, n'est que cela, la configuration

Par exemple, les informations sur l'ip et le port d'un proxy vont définitivement dans un fichier XML, c'est la configuration d'exécution.

Utiliser @Autowire, @Elementpour indiquer au cadre ce qu'il faut faire avec la classe est une bonne utilisation des annotations.

Mettre l'URL dans l' @Webserviceannotation est un mauvais style.

Mais ce n'est que mon avis. La frontière entre interaction et configuration n'est pas toujours claire.

J'utilise Spring depuis quelques années maintenant et la quantité de XML nécessaire devenait définitivement fastidieuse. Entre les nouveaux schémas XML et la prise en charge des annotations dans Spring 2.5, je fais généralement ces choses:

1. Utilisation de "component-scan" pour charger automatiquement les classes qui utilisent @Repository, @Service ou @Component. Je donne généralement un nom à chaque bean, puis je les connecte ensemble en utilisant @Resource. Je trouve que cette plomberie ne change pas très souvent, donc les annotations ont du sens.

2. Utilisation de l'espace de noms "aop" pour tous les AOP. Cela fonctionne vraiment très bien. Je l'utilise toujours aussi pour les transactions car mettre @Transactional partout est un peu un frein. Vous pouvez créer des pointcuts nommés pour des méthodes sur n'importe quel service ou référentiel et appliquer très rapidement les conseils.

3. J'utilise LocalContainerEntityManagerFactoryBean avec HibernateJpaVendorAdapter pour configurer Hibernate. Cela permet à Hibernate de découvrir facilement automatiquement les classes @Entity sur le chemin des classes. Ensuite, je crée un bean SessionFactory nommé en utilisant "factory-bean" et "factory-method" faisant référence au LCEMFB.

Un élément important dans l'utilisation d'une approche uniquement d'annotation est que le concept de «nom de bean» disparaît plus ou moins (devient insignifiant).

Les "noms de bean" dans Spring forment un niveau supplémentaire d'abstraction sur les classes d'implémentation. Avec XML, les beans sont définis et référencés par rapport à leur nom de bean. Avec les annotations, ils sont référencés par leur classe / interface. (Bien que le nom du bean existe, vous n'avez pas besoin de le connaître)

Je crois fermement que se débarrasser des abstractions superflues simplifie les systèmes et améliore la productivité. Pour les grands projets, je pense que les gains en se débarrassant de XML peuvent être substantiels.

Je pense que la visibilité est une grande victoire avec une approche basée sur XML. Je trouve que le XML n'est pas vraiment si mauvais, étant donné les différents outils disponibles pour naviguer dans les documents XML (par exemple, la fenêtre de structure de fichier de Visual Studio + ReSharper).

Vous pouvez certainement adopter une approche mixte, mais cela me semble dangereux ne serait-ce que parce que, potentiellement, il serait difficile pour les nouveaux développeurs d'un projet de déterminer où les différents objets sont configurés ou mappés.

Je ne sais pas; En fin de compte, XML Hell ne me semble pas si mal.

Cela dépend de tout ce que vous voulez configurer, car certaines options ne peuvent pas être configurées avec des annotations. Si nous le voyons du côté des annotations:

• plus: les annotations sont moins parlantes
• moins: les annotations sont moins visibles

C'est à vous ce qui est le plus important ...

En général, je recommanderais de choisir un moyen et de l'utiliser partout sur une partie fermée du produit ...

(à quelques exceptions près: par exemple, si vous choisissez des configurations basées sur XML, vous pouvez utiliser l'annotation @Autowire. C'est un mélange, mais celui-ci aide à la fois la lisibilité et la maintenabilité)

Il y a d'autres aspects à comparer comme la refactorisation et d'autres changements de code. lors de l'utilisation de XML, la refactorisation demande un effort sérieux car vous devez vous occuper de tout le contenu XML. Mais c'est facile lors de l'utilisation des annotations.

Ma méthode préférée est la configuration basée sur Java sans annotations (ou minimales). http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Je me trompe peut-être, mais je pensais que les annotations (comme dans @Tag de Java et [Attribute] de C #) étaient une option de compilation, et XML était une option d'exécution. Cela me dit qu'ils ne sont pas équivalents et ont des avantages et des inconvénients différents.

Je pense aussi qu'un mix est la meilleure chose, mais cela dépend aussi du type de paramètres de configuration. Je travaille sur un projet Seam qui utilise également Spring et je le déploie généralement sur différents serveurs de développement et de test. Alors je me suis séparé:

• Configuration spécifique au serveur (comme les chemins absolus vers les ressources sur le serveur): fichier XML Spring
• Injecter des beans en tant que membres d'autres beans (ou réutiliser une valeur définie par Spring XML dans de nombreux beans): Annotations

La principale différence est que vous n'avez pas à recompiler le code pour toutes les configurations changeantes spécifiques au serveur, il vous suffit de modifier le fichier xml. Il y a aussi l'avantage que certaines modifications de configuration peuvent être effectuées par des membres de l'équipe qui ne comprennent pas tout le code impliqué.

Dans le cadre du conteneur DI, je considère que la DI basée sur les annotations abuse de l'utilisation de l'annotation Java. En disant cela, je ne recommande pas de l'utiliser largement dans votre projet. Si votre projet a vraiment besoin de la puissance du conteneur DI, je recommanderais d'utiliser Spring IoC avec l'option de configuration basée sur Xml.

Si c'est juste pour des raisons de test unitaire, les développeurs doivent appliquer le modèle d'injection de dépendances dans leur codage et tirer parti d'outils moqueurs tels que EasyMock ou JMock pour contourner les dépendances.

Vous devriez essayer d'éviter d'utiliser le conteneur DI dans son mauvais contexte.

Les informations de configuration qui seront toujours liées à un composant Java spécifique (classe, méthode ou champ) sont un bon candidat pour être représentées par des annotations. Les annotations fonctionnent particulièrement bien dans ce cas lorsque la configuration est au cœur de l'objectif du code. En raison des limitations sur les annotations, il est également préférable que chaque composant ne puisse avoir qu'une seule configuration. Si vous avez besoin de gérer plusieurs configurations, en particulier celles qui sont conditionnelles à tout élément en dehors de la classe Java contenant une annotation, les annotations peuvent créer plus de problèmes qu'elles n'en résolvent. Enfin, les annotations ne peuvent pas être modifiées sans recompiler le code source Java, donc tout ce qui doit être reconfigurable au moment de l'exécution ne peut pas utiliser d'annotations.

Veuillez consulter les liens suivants. Ils pourraient également être utiles.

1. Annotations vs XML, avantages et inconvénients
2. http://www.ibm.com/developerworks/library/j-cwt08025/

C'est la question classique «Configuration contre Convention». Le goût personnel dicte la réponse dans la plupart des cas. Cependant, personnellement, je préfère la configuration (c'est-à-dire basée sur XML) à la convention. Les IDE de l'OMI sont suffisamment robustes pour surmonter certains des enfers XML que les gens associent souvent à la construction et au maintien d'une approche basée sur XML. En fin de compte, je trouve que les avantages de la configuration (tels que la création d'utilitaires pour créer, maintenir et déployer le fichier de configuration XML) l'emportent sur la Convention à long terme.

J'utilise les deux. Principalement XML, mais quand j'ai un tas de beans qui héritent d'une classe commune et ont des propriétés communes, j'utilise des annotations pour ceux-ci, dans la superclasse, donc je n'ai pas à définir les mêmes propriétés pour chaque bean. Parce que je suis un peu un maniaque du contrôle, j'utilise @Resource (name = "referBean") au lieu de simplement alimenter automatiquement des trucs (et me sauver beaucoup de problèmes si jamais j'ai besoin d'un autre bean de la même classe que le referBean d'origine) .

Il y a quelques avantages et inconvénients de la configuration d'annotation d'après mon expérience:

• En ce qui concerne la configuration JPA, car elle est effectuée une fois et n'est généralement pas modifiée assez souvent, je préfère m'en tenir à la configuration des annotations. Il y a peut-être un problème concernant la possibilité de voir une image plus grande de la configuration - dans ce cas, j'utilise des diagrammes MSQLWorkbench.
• La configuration XML est très bonne pour avoir une vue d'ensemble de l'application, mais il peut être difficile de trouver des erreurs jusqu'à l'exécution. Dans ce cas, l' annotation Spring @Configuration semble être un meilleur choix car elle vous permet également de voir une image plus grande et permet également de valider la configuration au moment de la compilation.
• En ce qui concerne la configuration Spring, je préfère combiner les deux approches: utilisez l' annotation @Configuration avec les interfaces Services et Query et la configuration xml pour les éléments de configuration dataSource et spring comme context: component-scan base-package = "..."
• Mais la configuration xml contient les annotations java en ce qui concerne la configuration des flux (Spring Web Flow ou Lexaden Web Flow) car il est extrêmement important d'avoir une vue d'ensemble de l'ensemble du processus métier. Et cela semble fastidieux de l'avoir implémenté avec l'approche des annotations.

Je préfère combiner les deux approches - annotations java et minimum xml essentiel qui minimisent l'enfer de configuration.

Pour Spring Framework, j'aime l'idée de pouvoir utiliser l'annotation @Component et de définir l'option "component-scan" afin que Spring puisse trouver mes beans java afin de ne pas avoir à définir tous mes beans en XML, ni en JavaConfig. Par exemple, pour les beans java singleton sans état qui doivent simplement être câblés à d'autres classes (via une interface idéalement), cette approche fonctionne très bien. En général, pour les beans Spring, je me suis pour la plupart éloigné de Spring XML DSL pour définir les beans, et je privilégie maintenant l'utilisation de JavaConfig et des annotations Spring car vous obtenez un certain temps de compilation pour vérifier votre configuration et un support de refactoring que vous ne faites pas. t obtenir avec la configuration XML de Spring. Je mélange les deux dans certains cas rares où j'ai constaté que JavaConfig / Annotations ne peut pas faire ce qui est disponible en utilisant la configuration XML.

Pour Hibernate ORM (je n'ai pas encore utilisé JPA), je préfère toujours les fichiers de mappage XML car les annotations dans les classes de modèle de domaine enfreignent dans une certaine mesure The Clean Architecture qui est un style architectural en couches que j'ai adopté ces dernières années. La violation se produit car elle nécessite que la couche principale dépende d'éléments liés à la persistance tels que les bibliothèques Hibernate ou JPA et rend les POJO de modèle de domaine un peu moins ignorants. En fait, la couche principale n'est pas censée dépendre du tout d'une autre infrastructure.

Cependant, si The Clean Architecture n'est pas votre "tasse de thé", alors je peux voir qu'il y a certainement des avantages (tels que la commodité et la maintenabilité) à utiliser les annotations Hibernate / JPA dans les classes de modèle de domaine sur des fichiers de mappage XML séparés.