Quand ne pas utiliser Spring pour instancier un bean?

J'essaie de comprendre quelle serait l'utilisation correcte de Spring. Pas syntaxiquement, mais en fonction de son objectif. Si l'on utilise Spring, le code Spring devrait-il remplacer tout le code d'instanciation du bean? Quand utiliser ou quand ne pas utiliser Spring, pour instancier un bean?

L'exemple de code suivant peut vous aider à comprendre mon dilemme:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = new ClassA();
    ca.setName(name);
    caList.add(ca);
}

Si je configure Spring, cela devient quelque chose comme:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
    ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
    ca.setName(name);
    caList.add(ca);
}

Personnellement, je pense que l'utilisation de Spring ici est une surcharge inutile, car

1. Le code le plus simple à lire / comprendre.
2. Ce n'est pas vraiment un bon endroit pour l'injection de dépendances car je ne m'attends pas à ce qu'il y ait une implémentation multiple / variée de ClassA, que j'aimerais pouvoir remplacer à l'aide de la configuration Spring à un moment ultérieur.

Suis-je en train de penser correctement? Sinon, où vais-je me tromper?

Vous avez raison, Spring n'est pas adapté au cas d'utilisation que vous avez indiqué. Spring est mieux utilisé pour gérer les dépendances externes (comme la connexion d'une connexion JDBC à un DAO) ou les configurations (comme la spécification du type de base de données à utiliser). Dans votre exemple, si le type de bean était susceptible de changer, vous utiliseriez une interface pour spécifier le bean et instancier les beans à l'aide d'une Factory. Vous utiliseriez Spring pour spécifier quelle fabrique utiliser, et l'injecteriez dans la classe qui avait besoin d'instancier les beans. Vous pouvez alors avoir plusieurs usines différentes qui ont créé plusieurs types de beans différents (qui prennent tous en charge l'interface du bean) et configurer celle qui convient au moment de l'installation (ou de la mise à jour).

J'utiliserais Spring (ou un autre système DI) entre les couches, une instanciation directe au sein des couches.
Ainsi, une classe qui crée un bean qui laisse la portée de cette classe à un système externe (fonctionnellement), éventuellement défini par ce système ou une couche de communication, serait créée via DI. Un autre bean créé uniquement pour un usage interne au sein de la couche application est créé directement, à la fois pour la clarté du code et (dans les grands systèmes tout aussi importants) pour des raisons de performances.

S'il s'agit d'un bean , vous devez laisser Spring le construire (sauf que vous pouvez fournir un bean d'usine - je l'ai utilisé là où je devais retourner une sous-classe spécifique dépendant d'une propriété système - et vous devriez consulter la documentation sur les annotations @Configurationet @Beansi vous faites cela). S'il ne s'agit pas d'un bean, mais plutôt d'un simple vieil objet Java, vous n'avez pas besoin d'utiliser Spring pour le faire. Les POJO sont utiles, mais n'obtiendront pas d'injection de dépendance, de wrappers AOP, etc. car ce sont les choses que Spring ajoute pour vous.

La décision fondamentale est de savoir s'il s'agit vraiment d'un bean ou simplement d'un objet ordinaire qui suit certaines conventions du bean (par exemple, la dénomination des méthodes). Je ne peux pas deviner ce qui est vraiment le cas d'après le petit exemple que vous avez donné.

Je peux me tromper, veuillez corriger.

Le concept entier de Bean dans le contexte du printemps est que Spring Container s'occupe de l'objet. C'est la naissance, c'est la portée du cycle de vie, la mort, etc ... C'est comme si c'était un gardien de l'objet. L'application qui en a besoin l'injecte.

Donc, tout en prenant une décision lors de la conception de votre module, pensez toujours si vous voulez que le framework Spring prenne soin ou s'il s'agit d'un simple objet dont le cycle de vie est enfermé dans une méthode.

Comme précédemment suggéré, les objets dao, les files d'attente jms, etc., sont lourds et il vaut mieux laisser à l'expert le framework Spring le soin de s'en occuper.