streamalism.org

1. Introduktion

Det er uden tvivl et af de vigtigste udviklingsprincipper for moderne softwaredesign Afhængighedsinjektion (DI) som helt naturligt strømmer ud af et andet kritisk vigtigt princip: Modularitet.

Denne artikel vil undersøge en bestemt type DI-teknik kaldet Konstruktørbaseret afhængighedsinjektion inden for foråret - hvilket ganske enkelt siger, betyder, at nødvendige komponenter overføres til en klasse på tidspunktet for instantiering.

For at komme i gang skal vi importere forårskontekst afhængighed i vores pom.xml:

 org.springframework spring-context 5.2.8.RELEASE 

Så er vi nødt til at oprette en Konfiguration fil. Denne fil kan enten være en POJO eller, hvis du foretrækker det, en XML-fil.

2. Kommentarbaseret konfiguration

Java-konfigurationsfil ligner stort set et almindeligt Java-objekt med nogle yderligere kommentarer:

@Configuration @ComponentScan ("com.baeldung.constructordi") public class Config {@Bean public Engine engine () {return new Engine ("v8", 5); } @Bean offentlig transmission transmission () {returner ny transmission ("glidende"); }} 

Her bruger vi annoteringer til at underrette Spring runtime om, at denne klasse er en udbyder af bønnedefinitioner (@Bønne annotation), og at en kontekstscanning efter yderligere bønner skal udføres i pakke com.baeldung.spring. Dernæst definerer vi en Bil klasse:

@Komponent offentlig klasse bil {@Autowired offentlig bil (motor motor, transmission transmission) {this.engine = motor; this.transmission = transmission; }}

Foråret møder vores Bil klasse, mens du foretager en pakkescanning og initialiserer sin forekomst ved at ringe til @Autowired kommenteret konstruktør.

Forekomster af Motor og transmission opnås ved at ringe @Bønne kommenterede metoder til Konfig klasse. Endelig er vi nødt til at starte en ApplicationContext ved hjælp af vores POJO-konfiguration:

ApplicationContext context = ny AnnotationConfigApplicationContext (Config.class); Bilbil = context.getBean (Car.class);

3. Implicit konstruktørinjektion

Fra og med forår 4.3 kan klasser med en enkelt konstruktør udelade @Autowired kommentar. En dejlig lille smule bekvemmelighed og fjernelse af kedelpladen!

Oven i det, også startende med 4.3, kan den konstruktørbaserede injektion udnyttes @Konfiguration kommenterede klasser. Og ja, hvis en sådan klasse kun har en konstruktør, så @Autowired kommentar kan også udelades.

4. XML-baseret konfiguration

En anden måde at konfigurere Spring runtime med konstruktørbaseret afhængighedsinjektion er at bruge en XML-konfigurationsfil:

Noter det konstruktør-arg kan acceptere en bogstavelig værdi eller en henvisning til en anden bønne og at en valgfri eksplicit indeks og type kan leveres. Type og indeks attributter kan bruges til at løse tvetydighed (for eksempel hvis en konstruktør tager flere argumenter af samme type).

navn attribut kunne også bruges til xml til java variabel matching, men derefter din kode skal kompileres med debug-flag på.

En Spring-applikationskontekst, i dette tilfælde, skal startes med ClassPathXmlApplicationContext:

ApplicationContext context = ny ClassPathXmlApplicationContext ("baeldung.xml"); Bilbil = context.getBean (Car.class);

5. Fordele og ulemper

Konstruktørinjektion har et par fordele sammenlignet med feltinjektion.

Den første fordel er testbarhed. Antag, at vi skal prøve en fjederbønne, der bruger feltinjektion:

offentlig klasse UserService {@Autowired privat UserRepository userRepository; }

Under opførelsen af ​​en UserService For eksempel kan vi ikke initialisere userRepository stat. Den eneste måde at opnå dette på er gennem Reflection API, som helt bryder indkapslingen. Den resulterende kode vil også være mindre sikker sammenlignet med et simpelt konstruktøropkald.

Derudover medfeltinjektion, kan vi ikke håndhæve klassens invariantere.Så det er muligt at have en UserService eksempel uden en korrekt initialiseret userRepository. Derfor kan vi opleve tilfældige NullPointerExceptions her og der. Også med konstruktionsinjektion er det lettere at bygge uforanderlige komponenter.

I øvrigt, at bruge konstruktører til at skabe objektforekomster er mere naturligt set fra OOP-synspunktet.

På den anden side er den største ulempe ved konstruktionsinjektion dens bredhed, især når en bønne har en håndfuld afhængighed. Nogle gange kan det være en velsignelse, da vi måske prøver hårdere på at holde antallet af afhængigheder minimalt.

6. Konklusion

Denne hurtige vejledning har vist det grundlæggende i to forskellige måder at bruge på Konstruktørbaseret afhængighedsinjektion ved hjælp af foråret rammer.

Det fuld implementering af denne vejledning kan findes på GitHub.