printemps-: pourquoi-Spring-Cannot-Match-by-Name-for-Injection

Injection de dépendance à ressort: pourquoi ne peut-elle pas correspondre automatiquement au nom?

Le mécanisme d'injection de dépendance de Spring est principalement

basé sur le type , pas les noms. Lors de la rencontre de plusieurs types du même type (comme TenantDataSource), il ne reviendra pas automatiquement pour correspondre en fonction du nom du paramètre. En effet, Spring ne peut pas toujours garantir le nom du paramètre dans la méthode pour correspondre au nom de bean.

Java par défaut,

ne conservera pas le nom du paramètre dans le bytecode compilé. S'il n'y a pas de configuration spéciale, les noms de paramètres (par exemple, TenantAdataSource et TenantBdataSource) seront effacés pendant la compilation et les ont remplacés par des noms universels, tels que Arg0 et Arg1. Par conséquent, le printemps ne peut pas savoir que la locationadatasource fait référence au haricot appelé "Tenanta-Datasource".

Résolvez le problème de rétention du nom de paramètre

Vous pouvez utiliser le logo du compilateur pour conserver le nom du paramètre dans le code d'octet:

-parameters

Même si ce logo est utilisé, Spring ne correspondra toujours pas au nom du paramètre à moins que la configuration ne soit claire.

<code>javac -parameters MyClass.java</code>

Spring évite les hypothèses pour éviter les accidents. Par exemple, si le nom du paramètre est accidentellement échangé ou nommé, ou si les développeurs s'attendent à des mappages différentes, que se passera-t-il? S'il n'y a pas de guidage clair (tel que

), Spring ne peut pas déterminer l'intention du développeur et choisir de lancer une erreur au lieu d'injecter le mauvais haricot.

@Qualifier Spring suit le principe de "explicitement mieux que caché". L'injection dépendante doit être prévisible et ne dépend pas des hypothèses des noms de paramètres à l'appariement de la correspondance du nom de bean. Le printemps est cohérent dans différents environnements et cadres. Certaines langues ou cadres (tels que Kotlin) conservent le nom du paramètre par défaut, tandis que d'autres langues ne sont pas conservées.

Quand la correspondance du nom peut-elle fonctionner automatiquement?

Bien que Spring ne correspond pas au nom du paramètre par défaut, il peut être égalé en fonction du nom du paramètre dans certains cas, mais cela dépend de vos paramètres:

Spring 4.3 Nom du paramètre Découverte

Si le code de compilation de logo , lorsqu'il y a une ambiguïté, le ressort peut déduire le nom du bean du nom du paramètre.

Exemple: -parameters

Si les noms de logo et de paramètres (TenantAdataSource, TenantBDataSource) et le nom de bean sont adaptés, le ressort peut résoudre l'ambiguïté. Cependant, ce comportement n'est pas toujours fiable ou prévisible dans une configuration complexe, c'est pourquoi la configuration d'affichage préférée (comme

).

<code>@Autowired
public TenantService(TenantDataSource tenantADataSource, TenantDataSource tenantBDataSource) {
    this.tenantADataSource = tenantADataSource;
    this.tenantBDataSource = tenantBDataSource;
}</code>

Pourquoi le printemps est-il plus enclin à utiliser @qualificier?

-parameters Utiliser pour assurer la définition et éliminer l'ambiguïté, afin que les développeurs et les cadres puissent clairement intention. @Qualifier

Exemple:

De cette manière, le printemps peut savoir avec précision quel haricot injecter, quel que soit le nom du paramètre ou d'autres facteurs.

Le ressort devrait être plus intelligent?

Certaines personnes peuvent penser qu'un cadre comme Spring devrait être plus intelligent, et le nom de bean est automatiquement adapté au nom du paramètre lorsqu'il y a une ambiguïté. Mais:

1. Compatibilité arrière : La modification automatique de ce comportement peut détruire les applications existantes qui ne correspondent pas au nom du bean et au nom du paramètre.
prévisibilité
2. : résolvez explicitement l'ambiguïté (par exemple, via ) pour s'assurer que les développeurs savent toujours quel haricot est injecté. Les hypothèses réaclables peuvent causer des difficultés à déboguer, en particulier dans les grandes applications complexes. @Qualifier
La situation dans la vraie scène

dans la plupart des applications réelles:

Les développeurs utilisent des noms de bean significatifs et des noms de paramètres, mais ils préfèrent également préférer

pour assurer leur clarté.
• @Qualifier pour les scènes multi-exemples,
Configurer dynamiquement
• ou Méthodes basées en usine (par exemple, abstractroutingatasorce), au lieu de connecter manuellement chaque bean.
points clés

Spring First Injects par type

: S'il n'y a qu'un seul type de bean, le printemps l'injectera sans aucun problème. S'il y a plusieurs haricots du même type, Spring nécessite des invites supplémentaires (telles que
1. ) pour résoudre l'ambiguïté. Le nom du paramètre n'est pas fiable. Même si le nom du paramètre (@Qualifier) est conservé, Spring évitera la correspondance de correspondance bien connue, à moins que la configuration ne soit claire.
2. explicite est meilleur que caché : la considération prioritaire de ressort peut être prévisible et encourage les développeurs à utiliser une configuration explicite (telle que ou -parameters) au lieu de compter sur une correspondance cachée.

3. Concept de conception de Spring : Les erreurs brumeuses peuvent empêcher les accidents et s'assurer que les développeurs contrôlent pleinement l'injection de dépendance. @Qualifier

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!