[JAVA] Les bases du printemps ~ Édition DI ~

À propos de DI

Qu'est-ce que DI

Autorisez l'application qui a créé l'instance directement à obtenir l'instance via le conteneur DI. Les avantages de l'utilisation de DI sont les suivants.

Le composant enregistré dans le conteneur DI est appelé "Bean". La configuration est appelée "Définition du bean".

Méthode de mise en œuvre par DI

Méthode de configuration

Déclaré comme une classe de configuration avec @Configuration Définition du bean avec @Bean

AppConfig.java


@Configuration
public class AppConfig {
    @Bean
    TestRepository testRepo() {
        retrun new TestRepositoryImpl();
    }
}

--xml base

Définition du bean dans l'élément . L'attribut id définit le nom du bean et l'attribut Class définit l'instance du bean de cette classe.

.xml


<beans>
<bean id="test" class="com.test.TestImpl" />
</beands>

--Base d'annotation

Méthode d'analyse d'une classe annotée pour la définition d'un bean et de son enregistrement dans un conteneur DI (analyse des composants). L'implémentation la plus intuitive.

Côté définition du haricot

TestImpl.java


@Component
publi classTestImpl implements Test {
}

Côté utilisateur Ajoutez @Autowired au constructeur pour l'injection automatique.

TestImpl.java


@Component
publi class TestUseImpl implements TestUse {
    @AutoWired
    public TestUseImpl(Test test) {
    }
}

Types d'injection

Il existe trois méthodes, mais l'injection du constructeur semble être bonne. Omis. L'injection constellaire semble recommandée car l'instance DI devient définitive. https://irof.hateblo.jp/entry/2017/04/16/222737 --Injection de set

À propos du câblage automatique

L'auto-câblage est un mécanisme qui injecte automatiquement dans un conteneur DI sans définir explicitement un bean avec @Bean. Résout en interne par type ou par nom. Cependant, si plusieurs conteneurs DI sont définis avec le même type, une erreur se produit car le conteneur DI n'a pas d'importance celui qui est utilisé. @Qualifier et @Resouce sont utilisés dans de tels cas.

Qualificateur et ressource

Supposons que vous enregistriez une méthode qui renvoie la même classe Convert dans le bean comme indiqué ci-dessous.

AppConfig


@Configuration
@ComponentScan
public class AppConfig {
    @Bean
    Convert getA() {
        return new ConvertA();
    }
    @Bean
    Convert getB() {
        return new ConvertB();
    }

En essayant d'injecter comme suit, le côté pg ne peut pas déterminer s'il faut injecter getA ou getB.

MainService


@Service
public class MainService {
    @Autowired
    private Convert getA;

    public String execute() {
        return getA.getConvert();
    }

Il est possible de séparer en spécifiant explicitement lequel injecter avec la description suivante.

@Qualifier("getA")
@Autowired
private Convert getA;
// @Resouce recherche dans le conteneur l'instance cible par nom de propriété, donc
//Si le nom correspond au nom de la propriété cible, il peut être omis.
@Resouce(name = "getA")Ou@Resouce
@Autowired
private Convert getA;

Mauvais exemple


@Service
public class MainService {
    private final Convert getA;
    
    @Resouce(name = "getA")
    public MainService (Convert a) {
        getA = a;
    }

    public String execute() {
        return getA.getConvert();
    }

Recommended Posts

Les bases du printemps ~ Édition DI ~
[Java] Spring DI ③
À propos de DI of Spring ①
Première botte à ressort (DI)
À propos de DI of Spring ②
[Pour les débutants] DI ~ Les bases de DI et DI au printemps ~
Introduction à Spring Boot ① ~ DI ~
[Java] Fonctionnement de Spring DI
À propos des annotations liées à Spring DI
[Java] Spring DI ④ --Gestion du cycle de vie
Notes de l'étude Spring Framework [Partie 1] Conteneur DI
DI SessionScope Bean dans le filtre Spring Boot 2