Hibernate: Design-Pattern für Abfragen, die nicht Objekte zurückgeben

glhlg

Mitglied
Guten Tag zusammen :)

mich würde mal eure Meinung interessieren.
Wenn ich meine DAO-Klasse habe, dann bekomme ich ja die entsprechenden POJOs.
Wenn ich jetzt aber zum Beispiel wissen möchte, wie viele Datensätze es mit der ID xy gibt, bei denen der Wert in einer weiteren Tabellenspalte true ist, dann gibt es verschiedene Ansätze, dieses herauszubekommen.

Ich könnte eine spezielle find- / get-Methode erstellen, die hardcoded diese Abfrage auf die Tabellenspalte enthält.
Oder die find-Methode hat einen weiteren Parameter, wo ich Criterion übergeben kann und ermittle den gesuchten Wert anhand von .size().
Oder ich frage alle mit der ID ab und gehe auf der Java-Seite in einer Schleife durch und frage die get-Methode der Objekt ab.
Die POJOs mit "schlauen" Methoden versehen schließe ich hier mal aus!!

Der Rückgabewert, der mich interessiert ist ja nun eigentlich eine Zahl. Ist es jetzt vom Design her schön, die DAO-Klasse mit Methoden auszustatten, die Zahlenwerte zurück geben? Ich finde eigentlich, da gehören nur Methoden rein, die dann Objekte zurückgeben (plus update(), delete(), ...).

Wo packe ich solche Abfragen hin? In eine eigene Klasse? Ruft die dann eine DAO-Methode auf, die eine Liste zurückgibt, die dann in der neuen Klasse ausgewertet wird?
Außerdem gibt es ja in größeren Projekten mit Sicherheit noch spezielle Abfragen, die SQL-spezifisch gestellt werden. Wo werden diese Methoden platziert?
Gibt es da ein schönes Design-Pattern?

Ich hoffe, ich habe mit meinem vielen Text nicht all zu stark verwirrt und konnte mein Problem klar machen! :confused:

Danke schon mal!
Gruß
Gerrit
 
Hallo,

für die einfachen lesenden operation nutze ich JPQL --> Vorteil Datenbankunabhängig

Wenn es komplexer wird schreib ich schonmal eine StoredProcedure die ich dann als NativeQuery aufrufe, wobei du in dann im Hibernate mapping file angeben kannst für welche db die query gültig ist.
 

Neue Beiträge

Zurück