streamalism.org

1. Oversikt

Spring Boot bruker en meningsfull algoritme for å skanne etter og konfigurere en Datakilde. Dette gjør at vi enkelt kan få en fullstendig konfigurert Datakilde implementering som standard.

I tillegg konfigurerer Spring Boot automatisk et lynrask tilkoblingsbasseng - enten HikariCP, Apache Tomcat eller Commons DBCP, i den rekkefølgen, avhengig av hvilke som er på klassestien.

Mens Spring Boot er automatisk Datakilde konfigurasjon fungerer veldig bra i de fleste tilfeller, noen ganger trenger vi et høyere nivå av kontroll, så vi må sette opp våre egne Datakilde implementering, og hopper over den automatiske konfigurasjonsprosessen.

I denne opplæringen lærer vi hvordan du konfigurerer en Datakilde programmatisk i Spring Boot.

2. Maven-avhengighetene

Opprette en Datakilde implementering er programmatisk grei, samlet sett.

For å lære hvordan du kan oppnå dette, implementerer vi et enkelt lagringslag som vil utføre CRUD-operasjoner på noen JPA-enheter.

La oss se på avhengighetene til demoprosjektet vårt:

 org.springframework.boot spring-boot-starter-data-jpa com.h2database h2 2.4.1 runtime 

Som vist ovenfor, bruker vi en H2-database-forekomst i minnet til å utøve lagringslaget. Ved å gjøre dette, vil vi kunne teste vår programmatisk konfigurerte Datakilde, uten kostnad for å utføre dyre databaseoperasjoner.

I tillegg, la oss sørge for å sjekke den nyeste versjonen av spring-boot-starter-data-jpa på Maven Central.

3. Konfigurere en Datakilde Programmatisk

Nå, hvis vi holder oss til Spring Boot's automatisk Datakilde konfigurasjon og kjøre prosjektet vårt i sin nåværende tilstand, vil det bare fungere som forventet.

Spring Boot vil gjøre alt det tunge infrastrukturrør for oss. Dette inkluderer å lage en H2 Datakilde implementering, som automatisk håndteres av HikariCP, Apache Tomcat eller Commons DBCP, og konfigurerer en databaseinstans i minnet.

I tillegg trenger vi ikke engang å lage en application.properties fil, da Spring Boot også vil gi noen standard databaseinnstillinger.

Som vi nevnte tidligere, til tider trenger vi et høyere nivå av tilpasning, derfor må vi konfigurere vårt eget Datakilde gjennomføring.

Den enkleste måten å oppnå dette på er å definere en Datakilde fabriksmetoden, og plassere den i en klasse som er merket med @Konfigurasjon kommentar:

@Configuration public class DataSourceConfig {@Bean public DataSource getDataSource () {DataSourceBuilder dataSourceBuilder = DataSourceBuilder.create (); dataSourceBuilder.driverClassName ("org.h2.Driver"); dataSourceBuilder.url ("jdbc: h2: mem: test"); dataSourceBuilder.username ("SA"); dataSourceBuilder.password (""); returner dataSourceBuilder.build (); }}

I dette tilfellet, vi brukte bekvemmeligheten DataSourceBuilder klasse - en ikke-flytende versjon av Joshua Blochs byggmønster - for å lage vår skikk programmatisk Datakilde gjenstand.

Denne tilnærmingen er veldig fin fordi byggherren gjør det enkelt å konfigurere en Datakilde bruker noen vanlige egenskaper. I tillegg bruker den også den underliggende tilkoblingsbassenget.

4. Eksternalisering Datakilde Konfigurasjon med application.properties Fil

Selvfølgelig er det også mulig å delvis eksternalisere vårt Datakilde konfigurasjon. For eksempel kunne vi definere noen grunnleggende Datakilde egenskaper i vår fabrikkmetode:

@Bean public DataSource getDataSource () {DataSourceBuilder dataSourceBuilder = DataSourceBuilder.create (); dataSourceBuilder.username ("SA"); dataSourceBuilder.password (""); returner dataSourceBuilder.build (); }

Og spesifiser noen flere i application.properties fil:

spring.datasource.url = jdbc: h2: mem: test spring.datasource.driver-class-name = org.h2.Driver 

Egenskapene definert i en ekstern kilde, slik som ovenfor application.properties filen eller via en klasse merket med @ConfigurationProperties, overstyrer de som er definert i Java API.

Det blir tydelig at med denne tilnærmingen vil vi ikke lenger beholde vår Datakilde konfigurasjonsinnstillinger lagret på ett sted.

På den annen side tillater det oss å holde konfigurasjonsinnstillinger for kompileringstid og kjøretid pent skilt fra hverandre.

Dette er veldig bra, ettersom det lar oss enkelt angi et konfigurasjonsbindingspunkt. På den måten kan vi inkludere forskjellige Datakilde innstillinger fra andre kilder, uten å måtte omorganisere våre bønnefabrikkmetoder.

5. Testing av Datakilde Konfigurasjon

Tester vår skikk Datakilde konfigurasjonen er veldig enkel. Hele prosessen koker bare til å opprette en JPA-enhet, definere et grunnleggende lagringsgrensesnitt og teste lagringslaget.

5.1. Opprette en JPA-enhet

La oss begynne å definere eksemplet vårt på JPA-enhetsklassen, som vil modellere brukere:

@Entity @Table (name = "brukere") offentlig klasse bruker {@Id @GeneratedValue (strategi = GenerationType.AUTO) privat lang id; privat strengnavn; privat streng e-post; // standard konstruktører / settere / getters / toString}

5.2. Et enkelt lagringslag

Deretter må vi implementere et grunnleggende lagringslag, som lar oss utføre CRUD-operasjoner i tilfeller av Bruker enhetsklasse definert ovenfor.

Siden vi bruker Spring Data JPA, trenger vi ikke lage vår egen DAO-implementering fra bunnen av. Vi må rett og slett utvide CrudRepository grensesnitt for å få en fungerende depotimplementering:

@Repository offentlig grensesnitt UserRepository utvider CrudRepository {} 

5.3. Testing av lagringslaget

Til slutt må vi sjekke at det er programmatisk konfigurert Datakilde fungerer faktisk. Vi kan enkelt oppnå dette med en integrasjonstest:

@RunWith (SpringRunner.class) @DataJpaTest offentlig klasse UserRepositoryIntegrationTest {@Autowired privat UserRepository userRepository; @Test offentlig ugyldig nårCalledSave_thenCorrectNumberOfUsers () {userRepository.save (ny bruker ("Bob", "[email protected]")); Liste brukere = (Liste) userRepository.findAll (); assertThat (users.size ()). erEqualTo (1); }}

De UserRepositoryIntegrationTest klasse er ganske selvforklarende. Det utøver ganske enkelt to av lagringsgrensesnittets CRUD-metoder for å vedvare og finne enheter.

Legg merke til at uansett om vi bestemmer oss for å programmere vår konfigurasjon Datakilde implementering, eller dele den opp i en Java-konfigurasjonsmetode og application.properties fil, bør vi alltid få en fungerende databasetilkobling.

5.4. Kjører prøveprogrammet

Endelig kan vi kjøre demo-applikasjonen vår ved hjelp av en standard hoved() metode:

@SpringBootApplication public class Application {public static void main (String [] args) {SpringApplication.run (Application.class, args); } @Bean offentlig CommandLineRunner-kjøring (UserRepository userRepository) kaster Unntak {retur (String [] args) -> {User user1 = new User ("John", "[email protected]"); Bruker bruker2 = ny bruker ("Julie", "[e-postbeskyttet]"); userRepository.save (user1); userRepository.save (user2); userRepository.findAll (). forEach (user -> System.out.println (user);};}} 

Vi har allerede testet depotlaget, så vi er sikre på at vårt Datakilde er konfigurert. Dermed, hvis vi kjører eksempelprogrammet, bør vi se i konsollutgangen listen over Bruker enheter som er lagret i databasen.

6. Konklusjon

I denne veiledningen, vi lærte å konfigurere en Datakilde implementering programmatisk i Spring Boot.

Som vanlig er alle kodeeksemplene som vises i denne opplæringen tilgjengelig på GitHub.