Hibernate Interceptors

1. Oversikt

I denne diskusjonen vil vi se på forskjellige måter å fange opp operasjoner innen Hibernates abstrakte relasjonelle kartlegging implementering.

2. Definere dvalemodusinterceptorer

Hibernate Interceptor er et grensesnitt som lar oss reagere på visse hendelser i dvalemodus.

Disse avlytterne er registrert som tilbakeringinger og gir kommunikasjonskoblinger mellom Hibernates økt og applikasjon. Med en slik tilbakeringing kan et program fange opp kjerne i dvalemodus som lagre, oppdatere, slette osv.

Det er to måter å definere interceptors på:

  1. implementering av org.hibernate.Interceptor grensesnitt
  2. utvide org.hibernate.EmptyInterceptor klasse

2.1. Implementering av en Interceptor Grensesnitt

Implementering org.hibernate.Interceptor krever implementering av ca. 14 medfølgende metoder. Disse metodene inkluderer onLoad, onSave, onDelete, findDirty, og noen flere.

Det er også viktig å sikre at alle klasser som implementerer Interceptor-grensesnittet kan serienummeres (implementerer java.io.Serialiserbar).

Et typisk eksempel vil se ut:

offentlig klasse CustomInterceptorImpl implementerer Interceptor, Serializable {@Override public boolean onLoad (Object entity, Serializable id, Object [] state, String [] propertyNames, Type [] types) throw CallbackException {// ... return false; } // ... @Override public String onPrepareStatement (String sql) {// ... return sql; }}

Hvis det ikke er spesielle krav, utvide Tom Interceptor klasse og bare overstyring av de nødvendige metodene anbefales på det sterkeste.

2.2. Forlenger Tom Interceptor

Utvide org.hibernate.EmptyInterceptor klasse gir en enklere måte å definere en interceptor på. Vi trenger nå bare å overstyre metodene som er relatert til operasjonen vi vil avskjære.

For eksempel kan vi definere vår CustomInterceptor som:

offentlig klasse CustomInterceptor utvider EmptyInterceptor {}

Og hvis vi trenger å fange opp datalagringsoperasjoner før de utføres, må vi overstyre onSave metode:

@Override public boolean onSave (Object entity, Serializable id, Object [] state, String [] propertyNames, Type [] types) {if (entity instanceof User) {logger.info ((((User) entity) .toString ()) ; } returner super.onSave (enhet, id, tilstand, propertyNames, typer); }

Legg merke til hvordan denne implementeringen bare skriver ut enheten - hvis det er en Bruker.

Selv om det er mulig å returnere en verdi på ekte eller falsk, det er en god praksis å tillate forplantning av onSave hendelse ved å påkalle super.onSave ().

En annen brukssak ville være å gi et revisjonsspor for databaseinteraksjoner. Vi kan bruke onFlushDirty () metode for å vite når en enhet endres.

For Bruker objekt, kan vi bestemme oss for å oppdatere dens sist endret dato eiendom når endringer på enheter av typen Bruker skje.

Dette kan oppnås med:

@Override public boolean onFlushDirty (Object entity, Serializable id, Object [] currentState, Object [] previousState, String [] propertyNames, Type [] types) {if (entity instanceof User) {((User) entity) .setLastModified (new Dato()); logger.info (((bruker) enhet) .toString ()); } returner super.onFlushDirty (enhet, id, currentState, previousState, propertyNames, typer); }

Andre arrangementer som slett og laste (initialisering av objekt) kan avskjæres ved å implementere det tilsvarende slett og på Last metoder henholdsvis.

3. Registrering Avskjærere

En dvaleinterceptor kan enten registreres som Økt-skapt eller SessionFactory-omfang.

3.1. Session-scoped Interceptor

EN Økt-scoped interceptor er knyttet til en bestemt økt. Den opprettes når økten defineres eller åpnes som:

public static Session getSessionWithInterceptor (Interceptor interceptor) kaster IOException {return getSessionFactory (). withOptions () .interceptor (interceptor) .openSession (); }

I det ovennevnte registrerte vi eksplisitt en avlytter med en bestemt dvalemodus.

3.2. SessionFactory-skopet Interceptor

EN Sesjonsfabrikk-scoped interceptor er registrert før man bygger en SessionFactory. Dette gjøres vanligvis gjennom ApplyInterceptor metode på en SessionFactoryBuilder forekomst:

ServiceRegistry serviceRegistry = configureServiceRegistry (); SessionFactory sessionFactory = getSessionFactoryBuilder (serviceRegistry) .applyInterceptor (ny CustomInterceptor ()) .build ();

Det er viktig å merke seg at a Sesjonsfabrikk-scoped interceptor vil bli brukt på alle økter. Derfor må vi være forsiktige med å ikke lagre økt spesifikk tilstand - da denne interceptoren vil bli brukt av forskjellige økter samtidig.

For en øktspesifikk oppførsel anbefales det å eksplisitt åpne en økt med en annen interceptor som tidligere vist.

Til SessionFactoryavgrensede avlyttere, må vi naturligvis sørge for at det er trådsikkert. Dette kan oppnås ved å spesifisere en øktkontekst i egenskapsfilen:

hibernate.current_session_context_class = org.hibernate.context.internal.ThreadLocalSessionContext

Eller ved å legge dette til vår XML-konfigurasjonsfil:

 org.hibernate.context.internal.ThreadLocalSessionContext 

For å sikre seriabilitet, SessionFactoryavgrensede avlyttere må implementere les Løs metoden for Serialiserbar grensesnitt.

4. Konklusjon

Vi har sett hvordan vi kan definere og registrere dvalemodstandsavlyttere enten som Økt-skapt eller SessionFactory-skopet. I begge tilfeller må vi sørge for at avskjæringsenhetene kan serialiseres, spesielt hvis vi vil ha en serie som kan serieiseres.

Andre alternativer til interceptors inkluderer Hibernate Events og JPA Callbacks.

Og som alltid kan du sjekke ut hele kildekoden på Github.


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