Pourquoi les grandes entreprises interdisent-elles l'utilisation de l'annotation @Autowired dans les projets Spring Boot ?

public class SimpleMovieLister {

    // the SimpleMovieLister has a dependency on a MovieFinder
    private MovieFinder movieFinder;

    // a constructor so that the Spring container can inject a MovieFinder
    public SimpleMovieLister(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }

    // business logic that actually uses the injected MovieFinder is omitted...
}

基于构造函数注入的主要优点是可以将需要注入的字段声明为final， 使得它们会在类实例化期间被初始化，这对于所需的依赖项很方便。

2.2 基于Setter的依赖注入

在基于setter的依赖注入中，setter方法被标注为 @Autowired。一旦使用无参数构造函数或无参数静态工厂方法实例化Bean，为了注入Bean的依赖项，Spring容器将调用这些setter方法。

@Component
public class SetterBasedInjection {

    private InjectedBean injectedBean;

    @Autowired
    public void setInjectedBean(InjectedBean injectedBean) {
        this.injectedBean = injectedBean;
    }
}

和基于构造器的依赖注入一样，在官方文档中，基于Setter的依赖注入中的 @Autowired也可以省去。

public class SimpleMovieLister {

    // the SimpleMovieLister has a dependency on the MovieFinder
    private MovieFinder movieFinder;

    // a setter method so that the Spring container can inject a MovieFinder
    public void setMovieFinder(MovieFinder movieFinder) {
        this.movieFinder = movieFinder;
    }

    // business logic that actually uses the injected MovieFinder is omitted...
}

2.3 基于属性的依赖注入

在基于属性的依赖注入中，字段/属性被标注为 @Autowired。一旦类被实例化，Spring容器将设置这些字段。

@Component
public class FieldBasedInjection {
    @Autowired
    private InjectedBean injectedBean;
}

正如所看到的，这是依赖注入最干净的方法，因为它避免了添加样板代码，并且不需要声明类的构造函数。代码看起来很干净简洁，但是正如代码检查器已经向我们暗示的那样，这种方法有一些缺点。

3. Défauts d'injection de dépendances basées sur le champ

3.1 Les champs immuables ne peuvent pas être déclarés

L'injection de dépendances basée sur le champ sur les champs déclarés comme finaux/ immuable Cela ne fonctionne pas car ces champs doivent être instanciés lorsque la classe est instanciée. La seule façon de déclarer des dépendances immuables est d’utiliser l’injection de dépendances basée sur le constructeur.

3.2 Il est facile de violer le principe de conception à responsabilité unique

Dans la programmation orientée objet, les cinq principes de conception SOLID sont largement utilisés (généralement six principes de conception en Chine) pour améliorer la réutilisabilité du code. Lisibilité, fiabilité et maintenabilité

S dans SOLID représente le principe de responsabilité unique, c'est-à-dire qu'une classe ne devrait être responsable que d'une seule responsabilité, et tous les services fournis par cette classe ne devraient être responsables que de la responsabilité dont elle est responsable. pour Servir.

En utilisant l'injection de dépendances basée sur le champ, pour les classes fréquemment utilisées, au fil du temps, nous ajouterons progressivement de plus en plus de dépendances à la classe. Nous en sommes très satisfaits, et il est facile d'ignorer les dépendances dans la classe. . Mais si vous utilisez l'injection de dépendances basée sur le constructeur, à mesure que de plus en plus de dépendances sont ajoutées à la classe, le constructeur deviendra de plus en plus grand et nous pouvons dire d'un coup d'œil que quelque chose ne va pas.

Avoir un constructeur avec plus de 10 paramètres est un signe clair que la classe s'est transformée en une collection vaste et complète de fonctionnalités et doit être divisée en morceaux plus petits et plus maintenables.

Ainsi, même si l’injection de propriété n’est pas une cause directe de violation du principe de responsabilité unique, elle cache des signaux et nous permet de les ignorer facilement.

3.3 Étroitement couplé au conteneur d'injection de dépendances

La principale raison d'utiliser l'injection de dépendances basée sur le champ est d'éviter le code standard pour les getters et les setters ou la création de constructeurs pour les classes. En fin de compte, cela signifie que la seule façon de définir ces champs est d'instancier la classe via le conteneur Spring et de les injecter en utilisant la réflexion, sinon les champs resteront nuls.

Le modèle de conception d'injection de dépendance dissocie la création de dépendances de classe de la classe elle-même et transfère cette responsabilité au conteneur d'injection de classe, permettant à la conception du programme d'être découplée et de suivre les principes de responsabilité unique et d'inversion de dépendance (tout aussi fiables). Par conséquent, le découplage de la classe obtenu par les champs de câblage automatique est finalement perdu en le couplant à nouveau au conteneur d'injection de classe (Spring dans ce cas), rendant ainsi la classe inutile en dehors du conteneur Spring.

Cela signifie que si vous souhaitez utiliser votre classe en dehors du conteneur d'application, par exemple pour des tests unitaires, vous serez obligé d'utiliser le conteneur Spring pour instancier votre classe puisqu'il n'y a pas d'autre moyen possible (sauf la réflexion) de mettre en place champs de câblage automatique.

3.4 Dépendances cachées

Lors de l'utilisation de l'injection de dépendances, la classe affectée doit clairement exposer ces dépendances à l'aide d'une interface publique, en exposant les dépendances requises dans le constructeur, ou en utilisant des méthodes (setters) pour exposer les dépendances facultatives. Lors de l’utilisation de l’injection de dépendances basée sur le champ, ces dépendances sont essentiellement cachées au monde extérieur.

4. Résumé

Nous avons vu qu'il fallait éviter autant que possible l'injection sur le terrain car elle présente de nombreux inconvénients, aussi élégante soit-elle. L’approche recommandée consiste à utiliser l’injection de dépendances basée sur le constructeur et sur le setter.

Pour les dépendances requises, il est recommandé d'utiliser l'injection basée sur le constructeur, de les rendre immuables et d'empêcher qu'elles soient nulles. Pour les dépendances facultatives, il est recommandé d’utiliser une injection basée sur un setter.