Vårkjerne-merknader
• Kommentarer om vårstøvler
• Kommentarer om vårplanlegging
• Vårdataanmerkninger
• Kommentarer om vårbønner
1. Oversikt
Vi kan utnytte funksjonene til våren DI-motor ved hjelp av merknadene i org.springframework.beans.factory.annotation og org.springframework.context.annotation pakker.
Vi kaller ofte disse "Vårens kjerneannotasjoner", og vi vil gjennomgå dem i denne opplæringen.
2. DI-relaterte merknader
2.1. @Autowired
Vi kan bruke @Autowired til markere en avhengighet som våren skal løse og injisere. Vi kan bruke denne merknaden med en konstruktør, setter eller feltinjeksjon.
Konstruktørinjeksjon:
klasse Bil {Motor motor; @Autowired Car (Engine engine) {this.engine = engine; }}
Setterinjeksjon:
klasse Bil {Motor motor; @Autowired void setEngine (Engine engine) {this.engine = engine; }}
Feltinjeksjon:
klasse bil {@Autowired Engine motor; }
@Autowired har en boolsk argumentet kalt kreves med standardverdien ekte. Det innstiller vårens oppførsel når den ikke finner en passende bønne å wire. Når ekte, et unntak blir kastet, ellers er ingenting kablet.
Merk at hvis vi bruker konstruktørinjeksjon, er alle konstruktørargumenter obligatoriske.
Fra og med versjon 4.3 trenger vi ikke å kommentere konstruktører med @Autowired eksplisitt med mindre vi erklærer minst to konstruktører.
For mer informasjon besøk artiklene våre om @Autowired og konstruktørinjeksjon.
2.2. @Bønne
@Bønne markerer en fabrikkmetode som starter en vårbønne:
@Bean Engine engine () {return new Engine (); }
Våren kaller disse metodene når det kreves en ny forekomst av returtypen.
Den resulterende bønnen har samme navn som fabrikkmetoden. Hvis vi vil navngi det annerledes, kan vi gjøre det med Navn eller verdi argumentene for denne merknaden (argumentet verdi er et alias for argumentet Navn):
@Bean ("motor") Motor getEngine () {returner ny motor (); }
Merk at alle metodene er merket med @Bønne må være i @Konfigurasjon klasser.
2.3. @Kvalifiserende
Vi bruker @Kvalifiserende sammen med @Autowired til oppgi bønne-ID eller bønnenavn vi ønsker å bruke i tvetydige situasjoner.
Følgende to bønner implementerer for eksempel det samme grensesnittet:
klasse Sykkelutstyr kjøretøy {} klasse Bil implementerer kjøretøy {}
Hvis våren trenger å injisere en Kjøretøy bønne, ender det med flere samsvarende definisjoner. I slike tilfeller kan vi oppgi navnet på en bønne eksplisitt ved hjelp av @Kvalifiserende kommentar.
Bruke konstruktørinjeksjon:
@Autowired Biker (@Qualifier ("bike") Vehicle vehicle) {this.vehicle = vehicle; }
Bruke setterinjeksjon:
@Autowired void setVehicle (@Qualifier ("bike") Vehicle vehicle) {this.vehicle = vehicle; }
Alternativt:
@Autowired @Qualifier ("bike") ugyldig setVehicle (Vehicle vehicle) {this.vehicle = vehicle; }
Bruke feltinjeksjon:
@Autowired @Qualifier ("sykkel") Kjøretøyskjøretøy;
For en mer detaljert beskrivelse, vennligst les denne artikkelen.
2.4. @Krevd
@Krevd på settermetoder for å markere avhengigheter som vi ønsker å fylle ut gjennom XML:
@Required void setColor (strengfarge) {this.color = color; }
Ellers, BeanInitializationException vil bli kastet.
2.5. @Verdi
Vi kan bruke @Verdi for å injisere eiendomsverdier i bønner. Den er kompatibel med konstruktør, setter og feltinjeksjon.
Konstruktørinjeksjon:
Motor (@Value ("8") int cylinderCount) {this.cylinderCount = cylinderCount; }
Setterinjeksjon:
@Autowired void setCylinderCount (@Value ("8") int cylinderCount) {this.cylinderCount = cylinderCount; }
Alternativt:
@Value ("8") ugyldig setCylinderCount (int cylinderCount) {this.cylinderCount = cylinderCount; }
Feltinjeksjon:
@Value ("8") int cylinderCount;
Selvfølgelig er det ikke nyttig å injisere statiske verdier. Derfor kan vi bruke plassholderstrenger i @Verdi til ledningsverdier definert i eksterne kilder, for eksempel i .eiendommer eller .yaml filer.
La oss anta følgende .eiendommer fil:
motor.fuelType = bensin
Vi kan injisere verdien av motor.fuelType med følgende:
@Value ("$ {engine.fuelType}") String fuelType;
Vi kan bruke @Verdi selv med SpEL. Mer avanserte eksempler finner du i vår artikkel om @Verdi.
2.6. @Kommer an på
Vi kan bruke denne kommentaren til å lage våren initialiser andre bønner før den merkede. Vanligvis er denne oppførselen automatisk, basert på de eksplisitte avhengighetene mellom bønner.
Vi trenger bare denne merknaden når avhengighetene er implisitte, for eksempel innlasting av JDBC-drivere eller initialisering av statisk variabel.
Vi kan bruke @Kommer an på på den avhengige klassen som spesifiserer navnene på avhengighetsbønnene. Merknaden er verdi argument trenger en matrise som inneholder avhengighetsbønnenavnene:
@DependsOn ("engine") klasse Bil implementerer kjøretøy {}
Alternativt, hvis vi definerer en bønne med @Bønne merknad, bør fabrikkmetoden merkes med @Kommer an på:
@Bean @DependsOn ("fuel") Motor motor () {return new Engine (); }
2.7. @Lat
Vi bruker @Lat når vi vil initialisere bønnen lat. Som standard oppretter Spring alle singletonbønner ivrig ved oppstart / bootstrapping av applikasjonskonteksten.
Imidlertid er det tilfeller når vi trenger å lage en bønne når vi ber om det, ikke ved oppstart av applikasjonen.
Denne kommentaren oppfører seg annerledes avhengig av hvor vi nøyaktig plasserer den. Vi kan sette den på:
- en @Bønne merket bønnefabrikkemetode, for å forsinke metodeanropet (derav bønneskapelsen)
- en @Konfigurasjon klasse og alt inneholdt @Bønne metoder vil bli påvirket
- en @Komponent klasse, som ikke er en @Konfigurasjon klasse, vil denne bønnen initialiseres lat
- en @Autowired konstruktør, setter eller felt for å laste selve avhengigheten lat (via proxy)
Denne kommentaren har et argument som heter verdi med standardverdien på ekte. Det er nyttig å overstyre standardadferden.
For eksempel å merke bønner som skal lastes ivrig når den globale innstillingen er lat, eller konfigurere spesifikk @Bønne metoder for ivrig lasting i en @Konfigurasjon klasse merket med @Lat:
@Configuration @Lazy class VehicleFactoryConfig {@Bean @Lazy (false) Engine engine () {return new Engine (); }}
For ytterligere lesing, vennligst besøk denne artikkelen.
2.8. @Se opp
En metode kommentert med @Se opp forteller våren å returnere en forekomst av metodens returtype når vi påberoper den.
Detaljert informasjon om merknaden finner du i denne artikkelen.
2.9. @Hoved
Noen ganger må vi definere flere bønner av samme type. I disse tilfellene vil injeksjonen mislykkes fordi våren ikke har peiling på hvilken bønne vi trenger.
Vi så allerede et alternativ for å håndtere dette scenariet: merke alle ledningspunkter med @Kvalifiserende og spesifiser navnet på ønsket bønne.
Imidlertid trenger vi oftest en bestemt bønne og sjelden de andre. Vi kan bruke @Hoved for å forenkle denne saken: hvis vi merker den mest brukte bønnen med @Hoved det vil bli valgt på ukvalifiserte injeksjonspunkter:
@Komponent @ Primærklasse Bilredskaper Kjøretøy {} @Komponentklasse Sykkelredskaper Kjøretøy {} @Komponentklasse Sjåfør {@Kjøretøybil; } @Component class Biker {@Autowired @Qualifier ("bike") Kjøretøyskjøretøy; }
I forrige eksempel Bil er det primære kjøretøyet. Derfor, i Sjåfør klasse, våren injiserer en Bil bønne. Selvfølgelig, i Biker bønne, verdien av feltet kjøretøy vil være en Sykkel motstand fordi det er kvalifisert.
2.10. @Omfang
Vi bruker @Omfang å definere omfanget av en @Komponent klasse eller a @Bønne definisjon. Det kan være enten singleton, prototype, forespørsel, økt, globalSession eller noe tilpasset omfang.
For eksempel:
@Component @Scope ("prototype") klasse motor {}
3. Kommentarer om kontekstkonfigurasjon
Vi kan konfigurere applikasjonskonteksten med kommentarene som er beskrevet i denne delen.
3.1. @Profil
Hvis vi vil at våren skal bruk en @Komponent klasse eller a @Bønne metoden bare når en bestemt profil er aktiv, vi kan markere det med @Profil. Vi kan konfigurere navnet på profilen med verdi kommentaren til kommentaren:
@Component @Profile ("sportDay") sykkelutstyr kjøretøy {}
Du kan lese mer om profiler i denne artikkelen.
3.2. @Import
Vi kan bruke spesifikk @Konfigurasjon klasser uten komponentskanning med denne kommentaren. Vi kan tilby disse klassene @Import‘S verdi argument:
@Import (VehiclePartSupplier.class) klasse VehicleFactoryConfig {}
3.3. @ImportResource
Vi kan importere XML-konfigurasjoner med denne kommentaren. Vi kan spesifisere XML-filstedene med lokasjoner argument, eller med dets alias, verdi argument:
@Configuration @ImportResource ("classpath: /annotations.xml") klasse VehicleFactoryConfig {}
3.4. @PropertySource
Med denne kommentaren kan vi definere eiendomsfiler for applikasjonsinnstillinger:
@Configuration @PropertySource ("classpath: /annotations.properties") klasse VehicleFactoryConfig {}
@PropertySource utnytter Java 8 gjentatte kommentarfunksjon, noe som betyr at vi kan merke en klasse med den flere ganger:
@Configuration @PropertySource ("classpath: /annotations.properties") @PropertySource ("classpath: /vehicle-factory.properties") klasse VehicleFactoryConfig {}
3.5. @PropertySources
Vi kan bruke denne merknaden til å spesifisere flere @PropertySource konfigurasjoner:
@Configuration @PropertySources ({@PropertySource ("classpath: /annotations.properties"), @PropertySource ("classpath: /vehicle-factory.properties")}) klasse VehicleFactoryConfig {}
Merk at siden Java 8 kan vi oppnå det samme med den gjentatte kommentarfunksjonen som beskrevet ovenfor.
4. Konklusjon
I denne artikkelen så vi en oversikt over de vanligste vårkjerne-merknadene. Vi så hvordan du konfigurerer ledningene til bønner og applikasjonskontekst, og hvordan du merker klasser for komponentskanning.
Som vanlig er eksemplene tilgjengelige på GitHub.
Neste » Vårnettkommentarer