L'écriture de la configuration dans le code est plus intuitive et simple (certaines configurations ont été réalisées par Spring Boot lui-même), en utilisant la programmation en chaîne. . .
Utiliser les dépendances maven est plus rafraîchissant.
Mais je pense qu'il y a d'autres pièges

Parce qu'il existe de nombreuses configurations au printemps qui ne seront pas modifiées une fois la configuration terminée, et il n'est pas nécessaire de les modifier, comme les dépendances de la plupart des beans. Cela n'a aucun sens de mettre toutes ces configurations qui ne changeront pas en XML. Cela ne fera que rendre la configuration de plus en plus grande. Spring 3.x a été critiqué pour avoir trop de configurations, et c'est devenu une programmation basée sur la configuration, qui met le problème. la charrue avant les bœufs, il est donc préférable de mettre ces configurations presque statiques dans le code.
XML est plus pratique à modifier et peut prendre effet sans compilation, il est donc préférable de mettre en XML les configurations qui doivent être modifiées en fonction de l'environnement et de l'activité.
Spring Boot absorbe la configuration basée sur les conventions de Rails, ce qui réduit considérablement la configuration. Cependant, si vous n'êtes pas familier avec la configuration de sa configuration sous-jacente, vous risquez de rencontrer de nombreux problèmes.

Je me sens un peu sans voix à ce sujet aussi.
Si vous devez expliquer, la configuration Java avant l'ère Spring était impérative (écrite jusqu'au bout, en fonction de l'ordre d'exécution), qui a été changée en XML déclaratif À l'ère Spring Boot, configuration Java déclarative (décentralisée). plusieurs méthodes annotées, l'ordre d'exécution n'en dépend pas).
De nombreuses autres configurations peuvent être remplacées avec application.properties Cela aurait dû être fait il y a longtemps !

spring的发展，采用了约定优于配置的原则。
1.xml中维护bean之间的依赖关系，随着业务逻辑的增长变得臃肿。
2.在.java中的配置效率是没有xml效率高的。