Configuration XML versus configuration basée sur des annotations
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). Au fur et à 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 XML par rapport à la configuration basée sur Annotation et quels sont les avantages de la configuration basée sur Annotation par rapport à la configuration basée sur XML?
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, par contre, 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 transactionnelle avec une annotation est parfaitement 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 doit pas être incluse dans la classe, car si vous souhaitez maintenant injecter SubtypeX, vous devez modifier votre code, alors que vous aviez un contrat d'interface avant de toute façon, 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, alors je ne sais pas à quel point elles sont bonnes, mais je dirais que laisser la cartographie des beans à la base de données en XML est également une bonne chose, 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 en la matière), allez-y.
En général: si une annotation fournit une fonctionnalité et agit comme un commentaire en soi, 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 d'exploitation 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.
Il y a ici un problème plus vaste, celui des méta-données externalisées ou en ligne. Si votre modèle objet ne persistera jamais que dans un sens, les métadonnées en ligne (c'est-à-dire les annotations) sont plus compactes et 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 manières, l'externalisation des métadonnées (c'est-à-dire des descripteurs XML) devient plus appropriée.
Aucune des deux n'est meilleure, 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 il est connu qu'aucune d'elles n'est suffisante.
Je pense toujours aux annotations comme une sorte d'indicateur de ce dont une classe est capable, ou comment il interagit avec les autres.
Pour moi, la configuration XML de Spring est tout simplement 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 à l'exécution.
En utilisant @Autowire, @Element indiquer le cadre que faire avec la classe est un bon usage des annotations.
Mettre l'URL dans le @Webservice annotation est un mauvais style.
Mais ce n'est que mon avis. La ligne 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 les 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 de l'espace de noms "aop" 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 pointcuts nommés pour les méthodes sur 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 "factory-method" en référence à LCEMFB.
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 certainement 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; En fin de compte XML, l'enfer ne me semble pas si mal.
Un aspect important de l’utilisation d’une approche d’annotation uniquement est que le concept de "nom de haricot" disparaît plus ou moins (devient insignifiant).
Les "noms de beans" dans Spring forment un niveau supplémentaire d'abstraction par rapport aux 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 haricot existe, vous n'avez pas besoin de le savoir)
Je crois fermement que l'élimination des abstractions superflues simplifie les systèmes et améliore la productivité. Pour les projets grands, je pense que les gains en supprimant XML peuvent être substantiels.
Il y a d'autres aspects à 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 c'est facile lorsque vous utilisez des annotations.
Ma méthode préférée est la configuration basée sur Java sans annotations (minimes). http://static.springsource.org/spring/docs/3.0.x/spring-framework- reference/html/beans.html # beans-Java
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 bavardes
- moins: les annotations sont moins visibles
C'est à vous de décider ce qui est le plus important ...
En général, je recommanderais de choisir un moyen et de l’utiliser sur une partie fermée du produit ...
(à quelques exceptions près: par exemple, si vous choisissez une configuration basée sur XML, il est correct d'utiliser l'annotation @Autowire. Elle mélange, mais elle facilite la lisibilité et la maintenabilité.)
Je pense aussi que la meilleure solution est de faire un mélange, 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 suffit de modifier le fichier xml. Il y a également 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é.
Je me trompe peut-être, mais je pensais que les annotations (comme dans l'attribut] des balises @Tag et C # de Java étaient une option de compilation et que XML était une option de l'exécution. Pour moi, cela ne signifie pas qu'ils ne sont pas équivalents et ont des avantages et des inconvénients différents.
Dans le cadre du conteneur DI, je considère que les annotations basées sur DI utilisent abusivement 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 une option de configuration basée sur XML.
S'il s'agit simplement d'un test unitaire, 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 spécifique Java (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 relatives aux 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 situé 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.
J'utilise les deux. Généralement XML, mais quand j'ai un tas de beans héritant d'une classe commune et ayant des propriétés communes, j'utilise des annotations pour ceux-ci, dans la superclasse, de sorte que 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 (nom = "référéBean") au lieu de trucs auto-câblés (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é original) .
D'après mon expérience, il y a quelques 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 y a peut-être un problème concernant la possibilité d'avoir une vue d'ensemble de la configuration - dans ce cas, j'utilise les diagrammes MSQLWorkbench.
- La configuration XML est très utile pour obtenir une image plus grande de l'application, mais il peut être fastidieux de détecter des erreurs jusqu'au moment de 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: utilisation de @ Configuration annotation avec les interfaces Services et Query et de la configuration xml pour dataSource et de la configuration de type Spring, tels que context: composant-scan base-package = "... "
- Mais bits de configuration xml 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 image plus complète du processus de gestion dans son ensemble. de l'avoir mis en œuvre avec l'approche des annotations.
Je préfère combiner les deux approches - Java et minimums essentiels xml qui minimisent 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" de sorte que Spring puisse trouver mes Java beans de sorte que je n'ai pas à définir tous mes beans en XML, ni dans JavaConfig.Par exemple, pour les stateans singleton sans stat Java 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. La configuration XML de Spring ne me permet pas de combiner 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 jusqu'à un certain point The Clean Architecture , qui est un style architectural par couches que j'ai adopté par le passé. quelques années. La violation se produit car elle oblige la couche de base à dépendre d'éléments liés à la persistance, tels que les bibliothèques Hibernate ou JPA, et à ignorer un peu moins les objets POJO de modèle de domaine. 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 constate que l'utilisation des annotations Hibernate/JPA dans les classes de modèle de domaine présente des avantages (tels que la commodité et la facilité de maintenance) par rapport à des fichiers de mappage XML distincts.
C’est la question classique de la "configuration contre 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 construire, maintenir et déployer le fichier de configuration XML) l’emportent sur la Convention à long terme.