Hibernate: Event Listener oder Interceptor, was sind die Vor- / Nachteile in der Praxis?

8

Ich werde eine Funktion implementieren, um eine ID in einer Tabelle zu aktualisieren, nachdem Hibernate meine Löschungen ausführt. Aber ich möchte ein Feedback darüber bekommen, welcher Ansatz besser ist. Auch in der Tabelle, in der ich den Wert aktualisiere, weiß Hibernate nichts darüber, also müsste ich gerade ein jdbc-Update machen - ist das überhaupt möglich?

    
non sequitor 09.10.2009, 19:21
quelle

3 Antworten

8

Was die Verwendung von Listener / Interceptor betrifft, würde ich mit Listener gehen - es ist flexibler in Bezug auf Ereignisse, die angehört werden können. Der Hauptzweck des Interceptors besteht darin, Objekteigenschaften vorher auf ein Ereignis zu prüfen / zu ändern (z. B. Löschen); während der Listener so konfiguriert werden kann, dass er "PostDelete" -Ereignis hört oder viele andere .

Wenn diese Tabelle jedoch nicht zugeordnet ist, warum brauchen Sie beides? Sie können es stattdessen direkt in Ihrem Code aktualisieren, nachdem Sie delete () aufgerufen haben (oder nachdem Sie flush () aufgerufen haben, wenn ein Fremdschlüssel beteiligt ist).

Sie können das auch in einem Trigger tun (möglicherweise; abhängig davon, ob die notwendigen Informationen in der Datenbank natürlich verfügbar sind).

    
ChssPly76 09.10.2009, 21:11
quelle
2

Es scheint, dass viele Listener bevorzugen - sie bieten eine breitere Liste von Ereignissen und sind flexibler, aber es gibt Dinge, die Interceptors anbietet und Listeners nicht.

Wenn Sie beispielsweise die Entität vor dem Speichern in der Datenbank ändern möchten, sollte ein Interceptor verwendet werden.

    
Andreea Hash 17.04.2015 14:32
quelle
1

Wie ich weiß, sind Interzeptoren die alte Implementierung des Hibernate-Teams und die Listener sind die neue flexible Version von Interzeptoren. Imho ist es einfacher zu verwenden Ruhezustand Listener als Interzeptoren.

    
moohkooh 22.11.2010 07:37
quelle

Tags und Links