streamalism.org

1. Introduktion

I denne vejledning skal vi gennemgå forskellige varianter af BeanFactory.getBean () metode.

Kort sagt, som navnet på metoden også antyder, det herer ansvarlig for at hente en bønneinstans fra Spring container.

2. Spring Beans Setup

Lad os først definere et par forårsbønner til test. Der er flere måder, hvorpå vi kan give bøndefinitioner til Spring-containeren, men i vores eksempel bruger vi annoteringsbaseret Java-konfiguration:

@Configuration class AnnotationConfig {@Bean (name = {"tiger", "kitty"}) @Scope (value = "prototype") Tiger getTiger (String name) {returner ny Tiger (navn); } @Bean (name = "lion") Lion getLion () {returner ny løve ("Hardcoded lion name"); } interface dyr {}} 

Vi har oprettet to bønner. Løve har standard-singleton-omfanget. Tiger er udtrykkeligt indstillet til prototype-omfang. Derudover skal du bemærke, at vi definerede navne for hver bønne, som vi bruger i yderligere anmodninger.

3. Den getBean () API'er

BeanFactory giver fem forskellige underskrifter af getBean () metode, som vi skal undersøge i de følgende underafsnit.

3.1. Henter Bean efter navn

Lad os se, hvordan vi kan hente en Løve bønneinstans ved hjælp af sit navn:

Objekt løve = context.getBean ("løve"); assertEquals (Lion.class, lion.getClass ());

I denne variant giver vi et navn, og til gengæld får vi en forekomst af Objekt klasse, hvis der findes en bønne med det givne navn i applikationens sammenhæng. Ellers kaster både dette og alle andre implementeringer NoSuchBeanDefinitionException hvis bønneopslaget mislykkes.

Den største ulempe er, at efter at have hentet bønnen, skal vi kaste den til den ønskede type. Dette kan medføre en anden undtagelse hvis den returnerede bønne har en anden type, end vi forventede.

Antag, at vi prøver at få en Tiger ved hjælp af navnet "løve". Når vi kaster resultatet til Tiger, det vil kaste en ClassCastException:

assertThrows (ClassCastException.class, () -> {Tiger tiger = (Tiger) context.getBean ("lion");});

3.2. Henter bønne efter navn og type

Her skal vi specificere både navnet og typen på den anmodede bønne:

Løve løve = context.getBean ("løve", Lion.class);

Sammenlignet med den foregående metode er denne sikrere, fordi vi straks får oplysningerne om typefejl:

assertThrows (BeanNotOfRequiredTypeException.class, () -> context.getBean ("løve", Tiger.class)); }

3.3. Henter bønner efter type

Med den tredje variant af getBean (), det er nok kun at specificere bønnetypen:

Løve løve = context.getBean (Lion.class);

I dette tilfælde skal vi være særlig opmærksom på et potentielt tvetydigt resultat:

assertThrows (NoUniqueBeanDefinitionException.class, () -> context.getBean (Animal.class)); }

I eksemplet ovenfor, fordi begge Løve og Tiger implementere Dyr interface, blot at specificere type er ikke nok til entydigt at bestemme resultatet. Derfor får vi en NoUniqueBeanDefinitionException.

3.4. Henter bønne efter navn med konstruktorparametre

Ud over bønnenavnet kan vi også videregive konstruktorparametre:

Tiger tiger = (Tiger) context.getBean ("tiger", "Siberian");

Denne metode er lidt anderledes, fordi den kun gælder for bønner med prototype-omfang.

I tilfælde af singletoner får vi en BeanDefinitionStoreException.

Fordi en prototype bønne returnerer en nyoprettet instans hver gang den bliver anmodet om det fra applikationsbeholderen, vi kan levere konstruktørparametre on-the-fly når man påberåber sig getBean ():

Tiger tiger = (Tiger) context.getBean ("tiger", "Siberian"); Tiger secondTiger = (Tiger) context.getBean ("tiger", "Striped"); assertEquals ("Siberian", tiger.getName ()); assertEquals ("Striped", secondTiger.getName ());

Som vi kan se, hver Tiger får et andet navn alt efter hvad vi specificerede som en anden parameter, når vi anmodede om bønnen.

3.5. Henter bønner efter type med konstruktorparametre

Denne metode er analog med den sidste, men vi skal videregive typen i stedet for navnet som det første argument:

Tiger tiger = context.getBean (Tiger.class, "Shere Khan"); assertEquals ("Shere Khan", tiger.getName ());

Svarende til at hente en bønne ved navn med konstruktorparametre, denne metode gælder kun for bønner med prototype.

4. Overvejelser om anvendelse

På trods af at være defineret i BeanFactory interface, den getBean () Metoden er oftest tilgængelig via ApplicationContext. Typisk, vi ønsker ikke at bruge getBean () metode direkte i vores program.

Bønner skal håndteres af beholderen. Hvis vi vil bruge en af ​​dem, skal vi stole på afhængighedsinjektion snarere end et direkte opkald til ApplicationContext.getBean (). På den måde kan vi undgå at blande applikationslogik med rammerelaterede detaljer.

5. Konklusion

I denne hurtige vejledning gennemgik vi alle implementeringer af getBean () metode fra BeanFactory interface og beskrevet fordele og ulemper ved hver.

Alle kodeeksemplerne, der vises her, er tilgængelige på GitHub.