Printemps - Confusion sur la configuration?

Quelque part, j'ai lu que Spring offre plus de commodité que de configuration. Mais les gens de Spring apportent tellement de changements à la configuration, que je suis maintenant vraiment confus d'utiliser la configuration xml ou l'annotation.

J'aimerais que n'importe qui suggère une méthodologie infaillible ou une règle empirique dans l'utilisation du xml et des annotations.

Des exemples à SO pour montrer que de nombreux débutants comme moi se perdent dans la configuration.

• lien-1

  Je ne semble pas saisir la fonctionnalité derrière <context:annotation-config>et <context:component-scan>.

  D'après ce que j'ai lu, ils semblent gérer différentes annotations (@Required, @Autowired etc vs @Component, @Repository, @Service etc.) mais aussi d'après ce que j'ai lu, ils enregistrent les mêmes classes de post-processeur de bean.

  Pour me confondre encore plus, il y a un annotation-configattribut sur <context:component-scan>...

• lien 2

  J'ai toujours la balise d'analyse des composants:

  <context:component-scan base-package="com.mycompany.maventestwebapp" />

  mais j'ai aussi une autre balise (qui ressemble à une tâche similaire), celle-ci:

  <annotation-driven />

  Quelle est la différence entre ces deux balises? Une autre chose "étrange" est que l'exemple précédent (qui n'utilise pas la balise pilotée par annotation) est très similaire au projet créé par STS en utilisant le projet de modèle Spring MVC mais si je supprime la balise pilotée par annotation de sa configuration fichier le projet ne s'exécute pas et donnez-moi l'erreur suivante: HTTP Status 404 - ...

Spring 3.2 n'a plus besoin de cglib pour le proxy, mais les versions inférieures utilisent cglib. Une citation du blog springsource

Afin de générer de tels proxys, Spring utilise une bibliothèque tierce appelée cglib. Malheureusement, ce projet n'est plus actif. Dans Spring 3.2, il est très probable que Spring utilise Javassist à la place par défaut.

Est-ce suffisant pour suggérer que Spring est une confusion sur la configuration?

Spring vise à vous fournir un cadre où il existe une «convention sur la configuration». Cependant, la réalité est que les applications Spring ont besoin d'une certaine quantité de configuration.

Dans les versions Spring 2.5.x et antérieures, l'idiome commun était de fournir cette configuration via XML. Avec Spring 3.0+, la manière idiomatique est d'utiliser des annotations (quelque chose que Java EE6 / 7 encourage également).

En remarque, il peut être amusant (triste?) De voir une entité JPA annotée, il est plutôt facile d'ajouter 4+ annotations à un seul champ ....

<annotation-driven />

Vous devez spécifier le schéma XML d'où cela vient.

Très probablement, c'est dans le contexte de la stratégie de gestion des transactions JPA lors de la définition du gestionnaire de transactions (voir 9.5.6. Utilisation de @Transactional dans les documents de Spring)

Lorsque vous définissez la gestion des transactions par annotation - Spring AOP crée automatiquement des aspects pour que votre méthode démarre (ou vérifie l'existence) de la transaction avant l'invocation d'une méthode, puis valide (ou annule en cas d'exception) après la fin de l'ivokation de la méthode.

J'ai trouvé que la création d'IoC / Bean basée sur des annotations est pratique lorsque vous avez une implémentation singleton mais peut avoir besoin de l'échanger.

Par opposition à une situation où vous devrez peut-être réutiliser un bean à plusieurs reprises avec différentes classes / instances dépendantes.

Dans ces cas, je déclare le bean dans la configuration et je fais généralement l'injection par le constructeur de la dépendance dont j'ai besoin. Ensuite, dans la classe qui utilisera lesdits haricots I @Autowireet ensuite @Qualifier("")- c'est ainsi que les usines sont censées fonctionner.

Un singleton est une méthode d'usine qui ne renvoie qu'un seul résultat. Lorsque cela ne s'applique pas facilement, c'est lorsque vous devez le mélanger.

En ce qui concerne l'utilisation de l'analyse des composants par rapport à non, cela dépend vraiment des critères ci-dessus et d'un bon jugement. Je suis généralement très explicite sur l'analyse des composants du package. De cette façon, je peux créer un contexte d'application différent pour les tests où je peux simuler des dépendances externes (comme une base de données) tout en testant le reste de ma configuration IoC.

De plus, je n'ai pas @Componentde code de bibliothèque dans mon projet. Vous ne savez jamais quand / comment vous devrez utiliser un bean et si vous @Componentle faites, vous pouvez accidentellement le ramasser dans une analyse et vous limitez sa réutilisabilité. Pour ces cas, j'ai généralement un contexte d'application défini dans la bibliothèque avec des valeurs par défaut de déclaration de bean pratiques que mon projet principal PEUT inclure avec les importations dans son contexte d'application.

Pas de religion ici. Des expériences à transmettre

Spring propose des options, à l'origine il n'y avait que le câblage basé sur XML. Un câblage basé sur des annotations ultérieures a été ajouté.
Il est désormais possible (et de nombreuses personnes le font) d'utiliser un mélange des deux.
Il existe une documentation complète incluse avec Spring et / ou téléchargeable sur le site Web de springsource. Il y a une formation professionnelle (jamais fait, je ne peux pas en témoigner), et pas mal de bons livres (j'aime Pro Spring d'APress, choisissez la bonne version pour la version de Spring que vous utilisez).