Maison > Java > javaDidacticiel > Pourquoi l'injection de champ devrait-elle être évitée dans l'injection de dépendance Spring ?

Pourquoi l'injection de champ devrait-elle être évitée dans l'injection de dépendance Spring ?

Linda Hamilton
Libérer: 2024-12-27 14:28:10
original
959 Les gens l'ont consulté

Why Should Field Injection Be Avoided in Spring Dependency Injection?

L'injection sur le terrain et ses inconvénients

L'injection sur le terrain, par laquelle les beans sont injectés via des annotations @Autowired sur les champs, est souvent déconseillée. Pour délimiter cela, considérez ce qui suit :

@Component
public class MyComponent {
    @Autowired
    private Cart cart;
}
Copier après la connexion

Alternativement, l'injection de constructeur utilise l'approche suivante :

@Component
public class MyComponent {
    private final Cart cart;

    @Autowired
    public MyComponent(Cart cart){
       this.cart = cart;
    }
}
Copier après la connexion

Techniques d'injection

Il y a Il existe trois méthodes principales d'injection de dépendances :

  • Constructeur injection : Injecté via des constructeurs.
  • Méthode d'injection : Injecté via des setters ou d'autres méthodes.
  • Injection sur le terrain : Injecté directement dans les champs en utilisant la réflexion.

L'injection de champ, comme on le voit dans le premier exemple, correspond à la troisième option.

Directives d'injection

Spring préconise les directives d'injection suivantes :

  • Dépendances obligatoires : Utiliser l'injection de constructeur.
  • Facultatif ou modifiable dépendances : Utiliser l'injection de setter.
  • Éviter l'injection de champ : Utilisez-le uniquement dans des scénarios exceptionnels.

Inconvénients de l'injection de champ

L'injection sur le terrain est déconseillée pour plusieurs raisons :

  • Objets immuables : L'injection de constructeur facilite la création d'objets immuables, ce que l'injection de champ n'offre pas.
  • Couplage étroit : L'injection sur le terrain couple étroitement les classes avec le conteneur DI, entravant leur utilisation indépendante.
  • Instanciation défis : Sans réflexion et sans conteneur DI, les classes ne peuvent pas être instanciées, ce qui entrave les capacités de tests unitaires.
  • Dépendances cachées : L'injection de champ masque les dépendances, ce qui rend difficile de discerner la dépendance de la classe sur des composants externes.
  • Dépendances multiples : L'injection de champ permet l'accumulation sans entrave de dépendances.
  • Violation de la responsabilité : Les classes qui gèrent plusieurs responsabilités présentent souvent des dépendances excessives, violant potentiellement le principe de responsabilité unique.

Conclusion

L'injection de constructeurs et de poseurs doit être priorisée en fonction des besoins. L'injection sur le terrain doit généralement être évitée en raison de ses inconvénients, avec la commodité comme seul avantage.

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!

source:php.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Derniers articles par auteur
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal