Introduksjon til Dagger 2

1. Introduksjon

I denne veiledningen tar vi en titt på Dagger 2 - et raskt og lett rammeverk for avhengighetsinjeksjon.

Rammeverket er tilgjengelig for både Java og Android, men den høye ytelsen avledet av injeksjon av kompileringstid gjør det til en ledende løsning for sistnevnte.

2. Avhengighetsinjeksjon

Som en litt påminnelse er Dependency Injection en konkret anvendelse av det mer generiske Inversion of Control-prinsippet der strømmen av programmet styres av selve programmet.

Den implementeres gjennom en ekstern komponent som gir forekomster av objekter (eller avhengigheter) som andre objekter trenger.

Og forskjellige rammer implementerer avhengighetsinjeksjon på forskjellige måter. Spesielt er en av de mest bemerkelsesverdige av disse forskjellene om injeksjonen skjer ved kjøretid eller ved kompileringstid.

Kjøretid DI er vanligvis basert på refleksjon som er enklere å bruke, men langsommere ved kjøretid. Et eksempel på et kjøretids DI-rammeverk er våren.

Kompileringstid DI er derimot basert på kodegenerering. Dette betyr at alle tunge operasjoner utføres under kompilering. Kompileringstid DI gir kompleksitet, men fungerer generelt raskere.

Dagger 2 faller inn i denne kategorien.

3. Maven / Gradle-konfigurasjon

For å kunne bruke Dagger i et prosjekt, må vi legge til dolk avhengighet til vår pom.xml:

 com.google.dagger dolk 2.16 

Videre må vi også inkludere Dagger-kompilatoren som brukes til å konvertere våre merkede klasser til koden som brukes til injeksjonene:

 org.apache.maven.plugins maven-compiler-plugin 3.6.1 com.google.dagger dolk-kompilator 2.16 

Med denne konfigurasjonen vil Maven sende den genererte koden til mål / genererte kilder / merknader.

Av denne grunn, Vi må sannsynligvis konfigurere IDE ytterligere hvis vi vil bruke noen av kodefullføringsfunksjonene. Noen IDEer har direkte støtte for merkeprosessorer, mens andre kan trenge oss til å legge til denne katalogen i byggestien.

Alternativt, hvis vi bruker Android med Gradle, kan vi inkludere begge avhengigheter:

kompilere 'com.google.dagger: dolk: 2.16' annotationProcessor 'com.google.dagger: dolk-kompilator: 2.16'

Nå som vi har Dagger i prosjektet vårt, la oss lage et eksempel på et program for å se hvordan det fungerer.

4. Gjennomføring

For eksempel vil vi prøve å bygge en bil ved å injisere komponentene.

Nå, Dagger bruker standard JSR-330-merknader mange steder, ett vesen @Injiser.

Vi kan legge til merknadene i felt eller konstruktøren. Men siden Dagger støtter ikke injeksjon på private felt, vi går for konstruktørinjeksjon for å bevare innkapsling:

offentlig klasse bil {privat motor motor; private merkevare merkevare; @Inject public Car (Engine engine, Brand brand) {this.engine = engine; this.brand = merkevare; } // getters og setters}

Deretter implementerer vi koden for å utføre injeksjonen. Mer spesifikt vil vi lage:

  • en modul, som er en klasse som gir eller bygger objektenes avhengighet, og
  • en komponent, som er et grensesnitt som brukes til å generere injektoren

Komplekse prosjekter kan inneholde flere moduler og komponenter, men siden vi har et veldig grunnleggende program å gjøre, er en av hvert nok.

La oss se hvordan vi kan implementere dem.

4.1. Modul

For å lage en modul, vi trenger å kommentere klassen med @Module kommentar. Denne merknaden indikerer at klassen kan gjøre avhengigheter tilgjengelig for containeren:

@Module public class VehiclesModule {}

Deretter, vi trenger å legge til @Leverer kommentar om metoder som konstruerer våre avhengigheter:

@Module public class VehiclesModule {@Provides public Engine provideEngine () {return new Engine (); } @Provides @Singleton public Brand supplyBrand () {return new Brand ("Baeldung"); }}

Vær også oppmerksom på at vi kan konfigurere omfanget av en gitt avhengighet. I dette tilfellet gir vi singleton omfanget til vårt Merke forekomst slik at alle bilforekomster har samme merkeobjekt.

4.2. Komponent

Videre skal vi lage vårt komponentgrensesnitt. Dette er klassen som vil generere bilforekomster, injisere avhengigheter levert av VehiclesModule.

Enkelt sagt, vi trenger en metodesignatur som returnerer en Bil og vi trenger å merke klassen med @Komponent kommentar:

@Singleton @Component (modules = VehiclesModule.class) offentlig grensesnitt VehiclesComponent {Car buildCar (); }

Legg merke til hvordan vi passerte modulklassen vår som et argument til @Komponent kommentar. Hvis vi ikke gjorde det, ville ikke Dagger vite hvordan man skulle bygge bilens avhengighet.

Siden vår modul gir et enkelt objekt, må vi også gi samme omfang til komponenten vår fordi Dagger tillater ikke at uskopiske komponenter refererer til bindingsbånd.

4.3. Kundekode

Endelig kan vi løpe mvn kompilere for å utløse merkeprosessorer og generere injektorkoden.

Etter det finner vi komponentimplementeringen vår med samme navn som grensesnittet, bare prefikset med “Dolk“:

@Test offentlig ugyldighet gittGeneratedComponent_whenBuildingCar_thenDependenciesInjected () {VehiclesComponent component = DaggerVehiclesComponent.create (); Car carOne = component.buildCar (); Car carTwo = component.buildCar (); Assert.assertNotNull (carOne); Assert.assertNotNull (carTwo); Assert.assertNotNull (carOne.getEngine ()); Assert.assertNotNull (carTwo.getEngine ()); Assert.assertNotNull (carOne.getBrand ()); Assert.assertNotNull (carTwo.getBrand ()); Assert.assertNotEquals (carOne.getEngine (), carTwo.getEngine ()); Assert.assertEquals (carOne.getBrand (), carTwo.getBrand ()); }

5. Våranalogier

De som er kjent med våren, har kanskje lagt merke til noen paralleller mellom de to rammene.

Dolkens @Module kommentar gjør beholderen oppmerksom på en klasse på en veldig lignende måte som noen av Spring's stereotype merknader (for eksempel @Service, @Kontrollør...). Like måte, @Leverer og @Komponent tilsvarer nesten vårens @Bønne og @Se opp henholdsvis.

Våren har også sitt @Omfang kommentar, korrelerer med @Singleton, men merk her allerede en annen forskjell i at Spring antar et singleton-omfang som standard mens Dagger standard som Spring-utviklere kan referere til som prototype-omfanget, og påkaller leverandørmetoden hver gang en avhengighet er nødvendig.

6. Konklusjon

I denne artikkelen gikk vi gjennom hvordan du setter opp og bruker Dagger 2 med et grunnleggende eksempel. Vi vurderte også forskjellene mellom kjøretid og kompileringstid.

Som alltid er all koden i artikkelen tilgjengelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found