streamalism.org

1. Oversigt

Spring Boot bruger en meningsfuld algoritme til at scanne efter og konfigurere en Datakilde. Dette giver os mulighed for let at få en fuldt konfigureret Datakilde implementering som standard.

Derudover konfigurerer Spring Boot automatisk en lynhurtig forbindelsespool - enten HikariCP, Apache Tomcat eller Commons DBCP i den rækkefølge, afhængigt af hvilke der er på klassestien.

Mens Spring Boot er automatisk Datakilde konfiguration fungerer meget godt i de fleste tilfælde, nogle gange har vi brug for et højere niveau af kontrol, så vi bliver nødt til at oprette vores egne Datakilde implementering og dermed springer den automatiske konfigurationsproces over.

I denne vejledning lærer vi hvordan man konfigurerer en Datakilde programmatisk i Spring Boot.

2. Maven-afhængighederne

Oprettelse af en Datakilde implementering programmatisk er overordnet ligetil.

For at lære at opnå dette implementerer vi et simpelt lagerlag, som udfører CRUD-operationer på nogle JPA-enheder.

Lad os se på vores demo-projekts afhængigheder:

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

Som vist ovenfor bruger vi en H2-databaseinstans i hukommelsen til at udøve lageret. Dermed kan vi teste vores programmatisk konfigurerede Datakilde, uden omkostningerne ved at udføre dyre databaseoperationer.

Lad os desuden sørge for at kontrollere den nyeste version af spring-boot-starter-data-jpa på Maven Central.

3. Konfiguration af en Datakilde Programmatisk

Hvis vi holder os til Spring Boot's automatiske nu Datakilde konfiguration og køre vores projekt i dets nuværende tilstand, fungerer det bare som forventet.

Spring Boot vil gøre alt det tunge infrastruktur VVS for os. Dette inkluderer oprettelse af en H2 Datakilde implementering, som automatisk håndteres af HikariCP, Apache Tomcat eller Commons DBCP og opsætning af en databasehukommelse i hukommelsen.

Derudover behøver vi ikke engang at oprette en application.properties fil, da Spring Boot også indeholder nogle standarddatabaseindstillinger.

Som vi nævnte før, har vi til tider brug for et højere niveau af tilpasning, derfor bliver vi nødt til at konfigurere vores egen Datakilde implementering.

Den enkleste måde at opnå dette på er ved at definere en Datakilde fabriksmetoden og placere den i en klasse, der er kommenteret med @Konfiguration 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 tilfælde, vi brugte bekvemmeligheden DataSourceBuilder klasse - en ikke-flydende version af Joshua Blochs bygmønster - at skabe programmatisk vores skik Datakilde objekt.

Denne tilgang er rigtig god, fordi bygherren gør det let at konfigurere en Datakilde ved hjælp af nogle almindelige egenskaber. Derudover bruger den også den underliggende forbindelsespulje.

4. Eksternalisering Datakilde Konfiguration med application.properties Fil

Naturligvis er det også muligt at delvist eksternalisere vores Datakilde konfiguration. For eksempel kunne vi definere nogle grundlæggende Datakilde egenskaber i vores fabriksmetode:

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

Og specificer et par yderligere i application.properties fil:

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

Egenskaberne defineret i en ekstern kilde, såsom ovenstående application.properties fil eller via en klasse, der er kommenteret med @ConfigurationProperties, tilsidesætter dem, der er defineret i Java API.

Det bliver tydeligt, at vi med denne tilgang ikke længere holder vores Datakilde konfigurationsindstillinger gemt på et enkelt sted.

På den anden side tillader det os at holde konfigurationsindstillingerne for kompileringstid og kørselstid pænt adskilt fra hinanden.

Dette er rigtig godt, da det giver os mulighed for nemt at indstille et konfigurationsbindingspunkt. På den måde kan vi inkludere forskellige Datakilde indstillinger fra andre kilder uden at skulle omformulere vores bønnefabriksmetoder.

5. Test af Datakilde Konfiguration

Test af vores skik Datakilde konfigurationen er meget enkel. Hele processen koger bare ned til at oprette en JPA-enhed, definere en grundlæggende lagergrænseflade og teste lagerlagret.

5.1. Oprettelse af en JPA-enhed

Lad os begynde at definere vores eksempel på JPA-enhedsklasse, som modellerer brugere:

@Entity @Table (navn = "brugere") offentlig klasse bruger {@Id @GeneratedValue (strategi = GenerationType.AUTO) privat lang id; privat strengnavn; privat streng e-mail; // standardkonstruktører / settere / getters / toString}

5.2. Et simpelt lagerlag

Dernæst er vi nødt til at implementere et grundlæggende lagerlag, som giver os mulighed for at udføre CRUD-operationer i tilfælde af Bruger enhedsklasse defineret ovenfor.

Da vi bruger Spring Data JPA, behøver vi ikke oprette vores egen DAO-implementering fra bunden. Vi er simpelthen nødt til at udvide CrudRepository interface for at få en fungerende repository implementering:

@Repository offentlig grænseflade UserRepository udvider CrudRepository {} 

5.3. Test af lagerlagret

Endelig skal vi kontrollere, at vores programmatisk konfigurerede Datakilde fungerer faktisk. Vi kan let opnå dette med en integrationstest:

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

Det UserRepositoryIntegrationTest klasse er ret selvforklarende. Det udøver simpelthen to af lagergrænsefladens CRUD-metoder til at fortsætte og finde enheder.

Bemærk, at uanset om vi beslutter at konfigurere vores programmatisk Datakilde implementering eller opdele den i en Java-konfigurationsmetode og application.properties fil, skal vi altid få en fungerende databaseforbindelse.

5.4. Kørsel af prøveapplikationen

Endelig kan vi køre vores demo-applikation ved hjælp af en standard hoved () metode:

@SpringBootApplication public class Application {public static void main (String [] args) {SpringApplication.run (Application.class, args); } @Bean offentlig CommandLineRunner-kørsel (UserRepository userRepository) kaster Undtagelse {return (String [] args) -> {User user1 = new User ("John", "[email protected]"); Brugerbruger2 = ny bruger ("Julie", "[email protected]"); userRepository.save (user1); userRepository.save (user2); userRepository.findAll (). forEach (bruger -> System.out.println (bruger);};}} 

Vi har allerede testet lagerlagret, så vi er sikre på, at vores Datakilde er konfigureret med succes. Således, hvis vi kører prøveapplikationen, skal vi se listen i vores konsoloutput Bruger enheder, der er gemt i databasen.

6. Konklusion

I denne vejledning vi lærte at konfigurere en Datakilde implementering programmatisk i Spring Boot.

Som normalt er alle kodeeksempler vist i denne vejledning tilgængelige på GitHub.