Hibernate 5 Bootstrapping API

1. Oversikt

I denne opplæringen vil vi utforske den nye mekanismen der vi kan initialisere og starte en dvale SessionFactory. Vi vil spesielt fokusere på den nye native bootstrapping-prosessen da den ble redesignet i versjon 5.0.

Før versjon 5.0 måtte applikasjoner bruke Konfigurasjon klasse for å bootstrap SessionFactory. Denne tilnærmingen er nå avviklet, siden dokumentasjonen for dvalemodus anbefaler å bruke den nye API-en basert på ServiceRegistry.

For å si det enkelt, bygge en SessionFactory handler om å ha en ServiceRegistry implementering som holder Tjenester nødvendig av dvalemodus både under oppstart og kjøretid.

2. Maven-avhengigheter

Før vi begynner å utforske den nye bootstrapping-prosessen, må vi legge til dvale-kjerne jar-fil til prosjektets klassesti. I et Maven-basert prosjekt trenger vi bare å erklære denne avhengigheten i pom.xml fil:

 org. dvalemodus dvalekjerne 5.4.0.Final 

Siden Hibernate er en JPA-leverandør, vil dette også inkludere JPA API-avhengighet transitt.

Vi trenger også JDBC-driveren til databasen vi jobber med. I dette eksemplet bruker vi en innebygd H2-database:

 com.h2database h2 1.4.197 

Sjekk gjerne de nyeste versjonene av dvale-kjerne og H2-driver på Maven Central.

3. Bootstrapping API

Bootstrapping refererer til prosessen med å bygge og initialisere en SessionFactory.

For å oppnå dette formålet, må vi ha en ServiceRegistry som holder Tjenester nødvendig av dvalemodus. Fra dette registeret kan vi bygge en Metadata objekt som representerer programmets domenemodell og tilordning til databasen.

La oss utforske disse hovedobjektene mer detaljert.

3.1. Service

Før vi graver i ServiceRegistry konsept, må vi først forstå hva en Service er. I dvalemodus 5.0, a Service er en type funksjonalitet representert av grensesnittet med samme navn:

org.hibernate.service.Service

Som standard gir dvalemodus implementeringer for de vanligste Tjenester, og de er tilstrekkelig i de fleste tilfeller. Ellers kan vi bygge våre egne Tjenester for å enten endre de originale dvalefunksjonene eller legge til nye.

I neste avsnitt vil vi vise hvordan dvalemodus lager disse Tjenester tilgjengelig gjennom en lett container kalt ServiceRegistry.

3.2. ServiceRegistry

Det første trinnet i å bygge en SessionFactory er å skape en ServiceRegistry. Dette gjør det mulig å holde forskjellige Tjenester som gir funksjonalitetene som er nødvendige i dvalemodus og er basert på Java SPI-funksjonaliteten.

Teknisk sett kan vi se ServiceRegistry som et lett avhengighetsinjiseringsverktøy der bønner bare er av typen Service.

Det er to typer ServiceRegistry og de er hierarkiske.Den første er BootstrapServiceRegistry, som ikke har noen forelder og har disse tre nødvendige tjenestene:

  • ClassLoaderService: lar dvalemodus samhandle med ClassLoader av de forskjellige kjøretidsmiljøene
  • IntegratorService: kontrollerer oppdagelsen og styringen av Integrator tjeneste som gjør at tredjepartsapplikasjoner kan integreres med dvalemodus
  • StrategiVelger: løser implementeringer av ulike strategikontrakter

Å bygge en BootstrapServiceRegistry implementering, bruker vi BootstrapServiceRegistryBuilder fabrikk klasse, som gjør det mulig å tilpasse disse tre tjenestene på en typesikker måte:

BootstrapServiceRegistry bootstrapServiceRegistry = ny BootstrapServiceRegistryBuilder () .applyClassLoader () .applyIntegrator () .applyStrategySelector () .build ();

Den andre ServiceRegistry er den StandardServiceRegistry, som bygger på forrige BootstrapServiceRegistry og holder de tre Tjenester nevnt ovenfor. I tillegg inneholder den forskjellige andre Tjenester nødvendig av dvalemodus, oppført i StandardServiceInitiators klasse.

I likhet med forrige register bruker vi StandardServiceRegistryBuilder for å lage en forekomst av StandardServiceRegistry:

StandardServiceRegistryBuilder standardServiceRegistry = ny StandardServiceRegistryBuilder ();

Under panseret, den StandardServiceRegistryBuilder oppretter og bruker en forekomst av BootstrapServiceRegistry. Vi kan også bruke en overbelastet konstruktør til å passere en allerede opprettet forekomst:

BootstrapServiceRegistry bootstrapServiceRegistry = ny BootstrapServiceRegistryBuilder (). Build (); StandardServiceRegistryBuilder standardServiceRegistryBuilder = ny StandardServiceRegistryBuilder (bootstrapServiceRegistry);

Vi bruker denne byggmesteren til å laste en konfigurasjon fra en ressursfil, for eksempel standard dvalemodus.cfg.xml, og til slutt påkaller vi bygge() metoden for å få en forekomst av StandardServiceRegistry.

StandardServiceRegistry standardServiceRegistry = standardServiceRegistryBuilder .configure () .build ();

3.3. Metadata

Etter å ha konfigurert alle Tjenester nødvendig ved å sette i gang en ServiceRegistry begge typer BootstrapServiceRegistry eller StandardServiceRegistry, Vi må nå gi representasjon av applikasjonens domenemodell og databasekartlegging.

De MetadataSources klassen er ansvarlig for dette:

MetadataSources metadataSources = nye MetadataSources (standardServiceRegistry); metadataSources.addAnnotatedClass (); metadataSources.addResource ()

Deretter får vi en forekomst av Metadata, som vi bruker i det siste trinnet:

Metadata metadata = metadataSources.buildMetadata ();

3.4. SessionFactory

Det siste trinnet er å lage SessionFactory fra det tidligere opprettet Metadata:

SessionFactory sessionFactory = metadata.buildSessionFactory ();

Vi kan nå åpne en Økt og begynn å vedvare og lese enheter:

Sessionsøkt = sessionFactory.openSession (); Filmfilm = ny film (100L); session.persist (film); session.createQuery ("FROM Movie"). liste ();

4. Konklusjon

I denne artikkelen undersøkte vi trinnene som trengs for å bygge en SessionFactory. Selv om prosessen virker kompleks, kan vi oppsummere den i tre hovedtrinn: vi opprettet først en forekomst av StandardServiceRegistry, så bygde vi en Metadata objekt, og til slutt bygde vi SessionFactory.

Den fulle koden for disse eksemplene finner du på Github.


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