streamalism.org

1. Introduksjon

Det er uten tvil et av de viktigste utviklingsprinsippene for moderne programvaredesign Avhengighetsinjeksjon (DI) som helt naturlig strømmer ut av et annet kritisk viktig prinsipp: Modularitet.

Denne artikkelen vil utforske en bestemt type DI-teknikk som kalles Konstruktørbasert avhengighetsinjeksjon innen våren - som ganske enkelt sagt, betyr at nødvendige komponenter overføres til en klasse på tidspunktet for instantiering.

For å komme i gang må vi importere vår-kontekst avhengighet i vår pom.xml:

 org.springframework spring-context 5.2.8.RELEASE 

Da må vi sette opp en Konfigurasjon fil. Denne filen kan enten være en POJO, eller hvis du foretrekker det, en XML-fil.

2. Kommentarbasert konfigurasjon

Java-konfigurasjonsfilen ser ganske ut som et vanlig gammelt Java-objekt med noen ekstra kommentarer:

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

Her bruker vi merknader for å varsle Spring runtime om at denne klassen er en leverandør av bønnedefinisjoner (@Bønne merknad) og at en kontekstskanning for flere bønner må utføres i pakken com.baeldung.spring. Deretter definerer vi a Bil klasse:

@Component public class Car {@Autowired public Car (Engine engine, Transmission transmission) {this.engine = motor; denne.overføring = overføring; }}

Våren vil møte vår Bil klasse mens du gjør en pakkeskanning og vil initialisere forekomsten ved å ringe til @Autowired kommentert konstruktør.

Forekomster av Motor og girkasse vil bli oppnådd ved å ringe @Bønne merkede metoder for Konfig klasse. Til slutt må vi starte en ApplicationContext ved hjelp av vår POJO-konfigurasjon:

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

3. Implisitt konstruksjonsinjeksjon

Fra og med våren 4.3 kan klasser med en enkelt konstruktør utelate @Autowired kommentar. En fin liten bekvemmelighet og fjerning av kjele!

På toppen av det, også med start på 4.3, kan den konstruktørbaserte injeksjonen utnyttes @Konfigurasjon kommenterte klasser. Og ja, hvis en slik klasse bare har en konstruktør @Autowired kommentar kan også utelates.

4. XML-basert konfigurasjon

En annen måte å konfigurere vårkjøring med konstruktørbasert avhengighetsinjeksjon er å bruke en XML-konfigurasjonsfil:

Noter det konstruktør-arg kan godta en bokstavelig verdi eller en referanse til en annen bønne, og at en valgfri eksplisitt indeks og type kan leveres. Type og indeks attributter kan brukes til å løse tvetydighet (for eksempel hvis en konstruktør tar flere argumenter av samme type).

Navn attributt kan også brukes for xml til java variabel matching, men deretter koden din må kompileres med feilsøkingsflagg på.

En Spring-applikasjonskontekst, i dette tilfellet, må startes opp med ClassPathXmlApplicationContext:

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

5. Fordeler og ulemper

Konstruktørinjeksjon har noen fordeler sammenlignet med feltinjeksjon.

Den første fordelen er testbarhet. Anta at vi skal teste en vårbønne som bruker feltinjeksjon:

offentlig klasse UserService {@Autowired privat UserRepository userRepository; }

Under byggingen av en UserService For eksempel kan vi ikke initialisere userRepository stat. Den eneste måten å oppnå dette på er gjennom Reflection API, som fullstendig bryter innkapslingen. Den resulterende koden vil også være mindre sikker sammenlignet med en enkel konstruktøranrop.

I tillegg medfeltinjeksjon kan vi ikke håndheve invariantere på klassenivå.Så det er mulig å ha en UserService forekomst uten en riktig initialisert userRepository. Derfor kan vi oppleve tilfeldige NullPointerExceptions her og der. Også, med konstruktørinjeksjon, er det lettere å bygge uforanderlige komponenter.

Videre Å bruke konstruktører til å lage objektforekomster er mer naturlig fra OOP-synspunkt.

På den annen side er den største ulempen med konstruktørinjeksjon dens ordlighetsgrad, spesielt når en bønne har en håndfull avhengigheter. Noen ganger kan det være en velsignelse, da vi kan prøve hardere for å holde antall avhengigheter minimalt.

6. Konklusjon

Denne raske opplæringen har vist det grunnleggende om to forskjellige måter å bruke Konstruktørbasert avhengighetsinjeksjon ved hjelp av vårens rammeverk.

De full gjennomføring av denne veiledningen finner du på GitHub.