streamalism.org

1. Oversigt

I denne diskussion vil vi se på forskellige måder at opfange operationer inden for Hibernates abstrakte relationelle kortlægning implementering.

2. Definition af dvaleinterceptorer

Hibernate Interceptor er en grænseflade, der giver os mulighed for at reagere på bestemte begivenheder i dvale.

Disse interceptors er registreret som tilbagekald og giver kommunikationsforbindelser mellem Hibernates session og applikation. Med en sådan tilbagekaldelse kan en applikation opfange kerne i dvale, f.eks gem, opdater, slet osv.

Der er to måder at definere interceptors på:

1. gennemførelse af org.hibernate.Interceptor interface
2. udvide org.hibernate.EmptyInterceptor klasse

2.1. Implementering af en Interceptor Interface

Implementerer org.hibernate.Interceptor kræver implementering af ca. 14 ledsagende metoder. Disse metoder inkluderer onLoad, onSave, onDelete, findDirty, og et par mere.

Det er også vigtigt at sikre, at enhver klasse, der implementerer Interceptor-interface, kan serienummeres (implementerer java.io.Serializable).

Et typisk eksempel vil se ud:

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 der ikke er specielle krav, udvide Tom Interceptor klasse og kun at tilsidesætte de krævede metoder anbefales stærkt.

2.2. Forlænger Tom Interceptor

Udvidelse af org.hibernate.EmptyInterceptor klasse giver en lettere måde at definere en interceptor på. Vi har nu kun brug for at tilsidesætte de metoder, der vedrører den operation, vi ønsker at opfange.

For eksempel kan vi definere vores CustomInterceptor som:

offentlig klasse CustomInterceptor udvider EmptyInterceptor {}

Og hvis vi har brug for at opfange datalagringsoperationer, før de udføres, er vi nødt til at tilsidesætte onSave metode:

@Override public boolean onSave (Objektenhed, Serialiserbar id, Objekt [] tilstand, String [] propertyNames, Type [] typer) {if (enhedsforekomst af bruger) {logger.info ((((Bruger) enhed) .toString ()) ; } returner super.onSave (enhed, id, tilstand, propertyNames, typer); }

Bemærk, hvordan denne implementering blot udskriver enheden - hvis det er en Bruger.

Mens det er muligt at returnere en værdi på rigtigt eller falsk, det er en god praksis at tillade formering af onSave begivenhed ved at påberåbe sig super.onSave ().

En anden brugssag ville være at give et revisionsspor til databaseinteraktioner. Vi kan bruge onFlushDirty () metode til at vide, hvornår en enhed ændres.

Til Bruger objekt, kan vi beslutte at opdatere dens sidst ændret dato ejendom, hver gang ændringer på enheder af typen Bruger ske.

Dette kan opnås med:

@Override public boolean onFlushDirty (Objekt-enhed, Serialiserbar id, Objekt [] currentState, Object [] previousState, String [] propertyNames, Type [] types) {if (entity instanceof User) {((User) entity) .setLastModified (new Dato()); logger.info (((bruger) enhed) .toString ()); } returner super.onFlushDirty (enhed, id, currentState, previousState, propertyNames, types); }

Andre begivenheder såsom slet og belastning (objektinitialisering) kan opfanges ved at implementere det tilsvarende onSlet og onLoad metoder henholdsvis.

3. Registrering Opfangere

En dvaleinterceptor kan enten registreres som Session-afskåret eller SessionFactory-afgrænset.

3.1. Session-scoped Interceptor

EN Session-scoped interceptor er knyttet til en bestemt session. Det oprettes, når sessionen defineres eller åbnes som:

offentlig statisk Session getSessionWithInterceptor (Interceptor interceptor) kaster IOException {return getSessionFactory (). medOptions () .interceptor (interceptor) .openSession (); }

I ovenstående registrerede vi eksplicit en interceptor med en bestemt dvale.

3.2. SessionFactory-indrettet Interceptor

EN SessionFabrik-scoped interceptor registreres, før der bygges en SessionFactory. Dette gøres typisk gennem ApplyInterceptor metode på en SessionFactoryBuilder eksempel:

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

Det er vigtigt at bemærke, at en SessionFabrik-scoped interceptor vil blive anvendt på alle sessioner. Derfor skal vi være forsigtige med ikke at gemme sessionsspecifik tilstand - da denne interceptor vil blive brugt af forskellige sessioner samtidigt.

For en sessionsspecifik opførsel anbefales det eksplicit at åbne en session med en anden interceptor som tidligere vist.

Til SessionFactoryafgrænsede interceptors, skal vi naturligvis sikre, at det er trådsikkert. Dette kan opnås ved at specificere en sessionskontekst i egenskabsfilen:

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

Eller ved at tilføje dette til vores XML-konfigurationsfil:

 org.hibernate.context.internal.ThreadLocalSessionContext 

Også for at sikre seriabilitet, SessionFactoryafgrænsede interceptors skal implementere læseResolve metode til Serialiserbar interface.

4. Konklusion

Vi har set, hvordan man definerer og registrerer dvaleinterceptorer enten som Session-afskåret eller SessionFactory-indrettet. I begge tilfælde skal vi sikre, at interceptorerne kan serialiseres, især hvis vi vil have en serie, der kan serialiseres.

Andre alternativer til interceptors inkluderer Hibernate Events og JPA Callbacks.

Og som altid kan du tjekke den komplette kildekode på Github.