Pourquoi le printemps utilise-t-il ioc et di?

Je suis nouveau sur le printemps 5 et ma question est pourquoi le printemps utilise-t-il DI et IOC? Je veux dire, pourquoi devons-nous écrire les beans dans un XML (héritage) puis les créer là où nous en avons besoin ? Pourquoi n'utilisons-nous pas une méthode à la place qui nous donne cet objet, jusqu'à ce que nous voulions utiliser ce mécanisme complexe qui se produit dans le conteneur de printemps?

Et une autre question est, la lecture de XML ne ralentit-elle pas le programme? Parce que nous lisons à partir du disque dur de toute façon.

Note: Il est vrai que l'on peut utiliser des annotations, mais pour l'instant je souhaite poser une question sur la lecture à partir de xml.

Solution du problème

Spring IoC Container est le cœur de Spring Framework. Il crée les objets, configure et assemble leurs dépendances, gère l'ensemble de leur cycle de vie. Le conteneur utilise Dependency Injection (DI) pour gérer les composants qui composent l'application. Il obtient les informations sur les objets à partir d'un fichier de configuration (XML) ou d'un code Java ou d'annotations Java et d'une classe Java POJO. Ces objets sont appelés Beans. Étant donné que le contrôle des objets Java et leur cycle de vie n'est pas effectué par les développeurs, d'où le nom Inversion Of Control. Plus sur le lien ICI

Quant à votre première partie de la question.

pourquoi le printemps utilise-t-il DI

Pour permettre au développeur de garder son code lâche et de ne pas emmêler les classes, il garde votre code propre. Dans la conception orientée objet, la quantité de couplage fait référence à la mesure dans laquelle la conception d'une classe dépend de la conception d'une autre classe. En d'autres termes, à quelle fréquence les changements de la classe A entraînent-ils des changements liés à la classe B ? Un couplage étroit signifie que les deux classes changent souvent ensemble, un couplage lâche signifie qu'elles sont pour la plupart indépendantes. En général, un couplage lâche est recommandé car il est plus facile à tester et à entretenir.

Vous pouvez trouver cet article de Martin Fowler (PDF) utile.

Je veux dire pourquoi devons-nous écrire les beans dans un XML (héritage) puis le créer là où nous en avons besoin

Remarque : Nous écrivons le bean en XML et il est créé au démarrage de l'application lorsqu'elle examine la définition du bean. Techniquement, vous ne créez jamais de bean, vous récupérez uniquement le bean créé à partir du conteneur Spring (IOC) que Spring a créé pour vous lorsque vous avez commencé. ton application.

Nous écrivons un plan de bean, ou simplement un bean, afin qu'il puisse être construit, placé dans le conteneur Spring au démarrage de l'application, puis nous l'avons à notre disposition pour pouvoir le récupérer à l'aide de la méthode getBean. Tout l'intérêt de "pourquoi", c'est parce que par défaut tous les beans sont définis comme singleton, cela signifie que lorsque vous récupérez un bean et en faites ce que vous voulez, vous ne vous souciez pas de la mémoire ou de quoi que ce soit, Spring s'occupe de la beans pour vous s'ils sont définis comme un Singleton.

Deuxième question:

Et une autre question est, la lecture de XML ne ralentit-elle pas le programme? Parce que nous lisons à partir du disque dur de toute façon.

Il n'y a pas de différence de performances entre l'annotation ou XML, c'est juste une approche différente, je ne suis pas sûr de ce que vous entendez par "lecture depuis le disque dur", mais d'une manière ou d'une autre vous devrez configurer votre application, oui, de nombreux forums préfère fuir XML, mais à mon avis honnête, la seule raison en est que lorsque vous écrivez une mauvaise configuration en XML, il est beaucoup plus difficile de la trouver par rapport à la configuration en Java qui lèvera une exception. XML, les fichiers application.properties nécessitent un redéploiement de l'application, tandis que l'annotation et la configuration java nécessitent une recompilation de votre projet, donc les deux ont des "défauts", mais c'est normal et tout à fait compréhensible pour moi.

Mais au final, je crois que c'est une question de préférence, je connais personnellement pas mal de personnes qui combinent les annotations avec la configuration XML et elles en savent beaucoup plus sur Spring que moi.

Donc, en résumé, il est pénible d'écrire des beans et leur configuration, de même que vous pouvez écrire une classe avec des méthodes sans créer d'interface pour elle puisque le résultat sera le même, mais cela vous aidera à long terme puisque vous ne le faites pas vous devez vous soucier de la mémoire ou si vous avez détruit ce haricot ou si vous ne l'avez pas fait.

Ce serait bien que vous lisiez sur

1. Initialisation paresseuse des beans

2. Initialisation rapide des beans

Portée 3.Singleton des haricots

4. Portée du prototype de haricots