Configuration XML par rapport à la configuration basée sur les annotations [fermé]

https://stackoverflow.com/questions/182393

06-07-2019
|

Question

Dans quelques grands projets sur lesquels j'ai travaillé récemment, il semble 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?

La solution

Les annotations ont leur utilité, mais elles ne sont pas la solution miracle pour détruire 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 injection de dépendance 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 nécessitant 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 étant transactionnelle avec une annotation est tout à fait logique, car il s'agit d'une information qu'un programmeur souhaiterait probablement connaître. Mais une interface va être injectée en tant que sous-typeY au lieu d'un sous-typeX ne devrait pas être incluse dans la classe, car si vous souhaitez maintenant injecter SubtypeX, vous devez changer votre code, alors que vous aviez un contrat d'interface auparavant, alors avec XML, il vous suffirait de changer les mappages XML, ce qui est assez rapide et sans douleur.

Je n'ai pas utilisé les annotations JPA, je ne sais donc 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'endroit où il se trouve. L’information provenait de, elle devrait simplement se préoccuper de ce qu’elle peut faire avec ses informations. Mais si vous aimez JPA (je n’éprouve aucune expérience avec elle), allez-y.

En général: Si une annotation fournit une fonctionnalité et agit comme un commentaire en elle-même, et n'attache 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 détruit pas sa logique de fonctionnement et constitue également un bon commentaire au niveau du code. Sinon, cette information est probablement mieux exprimée en XML, car même si elle affectera éventuellement le fonctionnement du code, elle ne modifiera pas la fonctionnalité principale du code et n'appartiendra donc pas aux fichiers source.

Autres conseils

Il existe ici un problème plus vaste, celui des métadonnées externalisées ou en ligne. Si votre modèle d’objet ne persiste que dans un sens, les métadonnées en ligne (annotations, par exemple) sont plus compactes et plus lisibles.

Si, toutefois, 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 façons, l'externalisation des métadonnées (c'est-à-dire des descripteurs XML) devient plus appropriée.

Ni l'un ni l'autre ne sont meilleurs et les deux sont donc pris en charge, bien que les annotations soient plus à la mode. En conséquence, les nouvelles structures de type «cheveux sur feu» telles que JPA ont tendance à les mettre davantage en valeur. Des API plus matures, telles que la version native d'Hibernate, offrent les deux, car on sait qu'aucune d'elles n'est suffisante.

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

Pour moi, la configuration XML de printemps est tout simplement la suivante: configuration

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

En utilisant @Autowire , @Element pour indiquer au cadre que faire avec la classe est un bon usage des annotations.

Le fait d'insérer l'URL dans l'annotation @Webservice est un style incorrect.

Mais ce n’est que mon opinion. La ligne de démarcation entre interaction et configuration n’est pas toujours claire.

J'utilise Spring depuis quelques années maintenant et la quantité de XML requise devenait de plus en plus fastidieuse. Entre les nouveaux schémas XML et le support des annotations dans Spring 2.5, je fais habituellement les choses suivantes:

Utilisation de " composant-scan " pour charger automatiquement des classes qui utilisent @Repository, @Service ou @Component. Je donne généralement un nom à chaque grain, puis je les relie ensemble à l’aide de @Resource. Je trouve que cette tuyauterie ne change pas très souvent et que les annotations ont donc un sens.
Utilisation du " aop " espace de noms pour tous les AOP. Cela fonctionne vraiment bien. Je l'utilise encore pour les transactions aussi parce que mettre @Transactional partout est une sorte de frein. Vous pouvez créer des raccourcis nommés pour les méthodes de n'importe quel service ou référentiel et appliquer très rapidement les conseils.
J'utilise LocalContainerEntityManagerFactoryBean avec HibernateJpaVendorAdapter pour configurer Hibernate. Cela permet à Hibernate de découvrir automatiquement les classes @Entity sur le classpath. Ensuite, je crée un bean nommé SessionFactory en utilisant "factory-bean". et " méthode d'usine " faisant référence au LCEMFB.

Un aspect important de l’utilisation d’une approche basée uniquement sur les annotations est que le concept de "nom de bean" plus ou moins s'en va (devient insignifiant).

Les " noms de haricots " in 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. 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 savoir.)

Je suis fermement convaincu que l'élimination des abstractions superflues simplifie les systèmes et améliore la productivité. Pour les grands projets, je pense que les gains en supprimant XML peuvent être substantiels.

Je pense que la visibilité est une grande victoire avec une approche basée sur XML. Je trouve que le code XML n’est pas si mauvais, étant donné les divers outils disponibles pour la navigation dans les documents XML (c'est-à-dire la fenêtre de structure de fichiers de Visual Studio + ReSharper).

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

je ne sais pas; à la fin, XML Hell ne me semble pas si mal que ça.

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 de décider ce qui est le plus important ...

En général, je vous conseillerais de choisir une méthode et de l’utiliser sur une partie fermée du produit ...

(à quelques exceptions près: par exemple, si vous choisissez des configurations basées sur XML, il est correct d'utiliser l'annotation @Autowire. Elle mélange, mais celle-ci facilite la lisibilité et la maintenabilité.

Il existe un autre aspect à comparer, comme le refactoring et d’autres modifications de code. lors de l'utilisation de XML, il faut déployer des efforts considérables pour procéder à la refactorisation car il faut gérer tout le contenu XML. Mais il est facile d’utiliser Annotations.

Ma méthode préférée est la configuration basée sur Java sans annotations (ou minimales). http: // statique .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 l'attribut @Tag de Java et C #) étaient une option de compilation, et que XML était une option d'exécution. Selon moi, cela ne signifie pas qu'ils ont des avantages et des inconvénients différents.

Je pense aussi qu'un mélange est la meilleure chose à faire, 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. J'ai donc divisé:

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 dans plusieurs beans): Annotations

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

Dans la portée du conteneur DI, je considère que DI basée sur des annotations abuse de l'utilisation des annotations 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 vous recommanderais d’utiliser Spring IoC avec une option de configuration basée sur XML.

S'il ne s'agit que d'un test d'unité, les développeurs doivent appliquer le modèle Dependency Inject dans leur codage et tirer parti des outils de moquage 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) constituent un bon candidat pour être représentées par des annotations. Les annotations fonctionnent particulièrement bien dans ce cas lorsque la configuration est essentielle au but du code. En raison des limitations sur les annotations, il est également préférable que chaque composant ne puisse jamais avoir qu'une seule configuration. Si vous devez gérer plusieurs configurations, en particulier celles qui dépendent de 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. Par conséquent, tout élément devant être reconfigurable au moment de l'exécution ne peut pas utiliser d'annotations.

Veuillez vous référer aux liens suivants. Ils pourraient être utiles aussi.

C’est la question classique de la configuration par rapport à la convention. Le goût personnel dicte la réponse dans la plupart des cas. Cependant, personnellement, je préfère la configuration (basée sur XML) à la convention. Les IDE IMO sont suffisamment robustes pour surmonter une partie de l'enfer 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 la construction, la maintenance et le déploiement du fichier de configuration XML) sont plus importants que la convention à long terme.

J'utilise les deux. Généralement XML, mais quand j'ai un tas de beans qui héritent d'une classe commune et qui ont des propriétés communes, j'utilise des annotations pour ceux-ci, dans la superclasse, je n'ai donc 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 (nom = "référéBean") au lieu de simplement autoriser le câblage (et me épargne beaucoup de problèmes si j'ai besoin d'un autre haricot de la même classe que le référé d'origine. ).

D'après mon expérience, il existe certains avantages et inconvénients de la configuration des annotations:

En ce qui concerne la configuration JPA car elle est effectuée une fois et ne sont généralement pas modifiées assez souvent, je préfère m'en tenir à la configuration des annotations. Il existe peut-être un problème concernant la possibilité de voir une image plus grande de la configuration. Dans ce cas, j'utilise les diagrammes MSQLWorkbench.
La configuration XML est très utile pour avoir une vue d’ensemble de l’application, mais il peut être fastidieux 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 de 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 tels que context: composant-scan base-package = " ; ... "
Mais les bits de configuration xml des annotations java en ce qui concerne la configuration de flux (Spring Web Flow ou Lexaden Web Flow) car il est extrêmement important de disposer d’une vue plus globale du processus commercial dans son ensemble. Et cela semble fastidieux de le mettre en œuvre avec une approche annotée.

Je préfère combiner les deux approches: les annotations java et le minimum essentiel xml qui minimise la configuration.

Pour Spring Framework, j'aime bien l'idée de pouvoir utiliser l'annotation @Component et de définir l'option "composant-scan". Pour que Spring puisse trouver mes beans java, je n'ai pas à définir tous mes beans en XML ni en JavaConfig. Par exemple, pour les beans java singleton sans état qui doivent simplement être connecté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 la définition des beans et je préfère maintenant utiliser JavaConfig et Spring Annotations, car vous bénéficiez d'une vérification de la compilation de votre configuration et d'une prise en charge du refactoring que vous n'avez pas. t obtenir avec la configuration XML de printemps. Je mélange les deux dans certains cas rares où j'ai constaté que JavaConfig / Annotations ne peut pas faire ce qui est disponible avec 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 violent, dans une certaine mesure, L'architecture propre , qui est un style architectural par couches que j'ai adopté au cours des dernières années. La violation se produit car la couche de base dépend de choses liées à la persistance, telles que les bibliothèques Hibernate ou JPA, et rend les ignorants de modèle de domaine un peu moins persistant. En fait, la couche de base n'est supposée dépendre d'aucune autre infrastructure.

Cependant, si The Clean Architecture n’est pas votre "tasse de thé" Je peux alors constater que l’utilisation d’annotations Hibernate / JPA dans les classes de modèles de domaine présente des avantages (tels que la commodité et la facilité de maintenance) par rapport à des fichiers de mappage XML distincts.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow