Das Problem ist doch hibernate, weil es in HQL bzw in der Criteria API keine Unterstützung für JOINS am Modell vorbei gibt, z.B. durch JOIN-Kritierien die im Query selbst gesetzt werden. Klar, man kann natürlich richtiges SQL in Verbindung mit Hibernate verwenden, aber wozu dann Hibernate? Mit SQL an sich geht das wunderbar und es lässt sich auch ein Persistenz-Framework implementieren, welches Unterstützung dafür bietet. Habe selbst solch eins schon benutzt, nur leider ist das eine Projekt-interne Entwicklung. Hibernate mag ja für "Wald und Wiesen" Anwendungen reichen, aber nicht für größere Projekte ...
Hibernate ist kein Allheilmittel und es wäscht auch keine Kleider!
Weshalb Joins am (ORM-)Modell vorbei, ist das Design dermassen schlecht? Oder liegt das eher beim Projektmanagement?
Notfalls könnte man ja Views zu Hilfe nehmen. Aber Hibernate zu einem Wundermittel hochzustilisieren oder schlecht zu reden ist schnell gemacht. Für saubere Lösungen braucht es oft noch ein bisschen Fachwissen und Kreativität, egal wie gross ein Projekt ist.
Hibernate braucht für Joins zwischen Entitäten eine echte Foreign-Key Beziehung, was aber nicht immer vorhanden ist. Es ist einfach so, dass ein Datenbankmodell, welches vor ca 20 Jahren erstellt wurde und wegen irgendwelcher inkompatibilitäten zwischen verschiedenen Systemen hier und da "zurecht gebogen" werden muss. Natürlich kennen die DB-Designer die Normalformen, aber das lässt sich nicht immer so einfach umsetzen wie's auf der Hochschule gelerht wird ... Man kann darüber streiten ob es Unfähigkeit ist, aber Tatsache ist, dass Hibernate es nicht kann, die technische Möglichkeit aber besteht (und sogar wahrscheinlich recht einfach implementierbar ist). Hibernate ist in meinen Augen nicht fertig und wird zu unrecht in den Himmel gelobt.
PS: Nein, ich habe keine Lust Hibernate zu erweitern, da das Framework, was bei uns im Projekt verwendet wird eben tut und wir Hibernate nicht brauchen. Vielleicht wird Hibernate ja mal eine Alternative, da der Einsatz von freier Software schon verlockend ist.
Das Problem ist vermutlich eher, dass ebenfalls zwischen dem, was ein Entwickler und ein Kunde unter einem ordentlichen Datenbankmodell verstehen, Unterschiede bestehen können.
Für den Entwickler ist eine Entität eineindeutig durch einen zugehörigen Key repräsentiert, der Kunde möchte aber gerne nicht 1876430987 sehen, wenn er das Formular öffnet, sondern irgendwas "völlig schlüssiges", wie "WERNER_MEIER".
Das es einem dabei die Haare zu Berge stehen lässt, vor allem, wenn man auf Produkten anderer basiert, die sich dazu entschlossen haben, genau dies als Foreign Key zu deklarieren und dann daran denkt, welchen Aufwand man betreiben muss, um beim Neuanlegen einer Entität einen eineindeutigen Schlüssel sicherzustellen, ist nur allzu verständlich. Ich habe selbst oft genug vor diesem Problem gestanden. Da hilft dann nur ein ORM, dass einigermaßen flexibel damit umgehen kann.
Weshalb Joins am (ORM-)Modell vorbei, ist das Design dermassen schlecht? Oder liegt das eher beim Projektmanagement?
Notfalls könnte man ja Views zu Hilfe nehmen. Aber Hibernate zu einem Wundermittel hochzustilisieren oder schlecht zu reden ist schnell gemacht. Für saubere Lösungen braucht es oft noch ein bisschen Fachwissen und Kreativität, egal wie gross ein Projekt ist.
PS: Nein, ich habe keine Lust Hibernate zu erweitern, da das Framework, was bei uns im Projekt verwendet wird eben tut und wir Hibernate nicht brauchen. Vielleicht wird Hibernate ja mal eine Alternative, da der Einsatz von freier Software schon verlockend ist.
Für den Entwickler ist eine Entität eineindeutig durch einen zugehörigen Key repräsentiert, der Kunde möchte aber gerne nicht 1876430987 sehen, wenn er das Formular öffnet, sondern irgendwas "völlig schlüssiges", wie "WERNER_MEIER".
Das es einem dabei die Haare zu Berge stehen lässt, vor allem, wenn man auf Produkten anderer basiert, die sich dazu entschlossen haben, genau dies als Foreign Key zu deklarieren und dann daran denkt, welchen Aufwand man betreiben muss, um beim Neuanlegen einer Entität einen eineindeutigen Schlüssel sicherzustellen, ist nur allzu verständlich. Ich habe selbst oft genug vor diesem Problem gestanden. Da hilft dann nur ein ORM, dass einigermaßen flexibel damit umgehen kann.
lg
Erik