[linux-l] Was mich an WebApplikationen immer und?immerwiderAnkotzt...
Rocco Rutte
pdmef at gmx.net
Sa Aug 2 12:29:49 CEST 2008
Hi,
* Olaf Radicke wrote:
>Vorweg: Ich habe mir Hibernate nur theoretisch angeschaut.
>Klar, als Programmierer würde ich auch gerne den SQL-Code raus haben, aber die
>ganzen Stärken einer relationale DB verbaue ich mir damit. So weit ich
>gesehen und verstanden habe, ist nicht nur das ökonomische Speichern ein
>Problem, sondern auch das selektieren.
>Das extrahieren von Datensetzen aus der Datenbank über komplexe Unterabfragen
>mit Beziehungen über mehreren Relationen hinweg scheint mir schwer - wenn
>nicht sogar - unmöglich, jedenfalls nicht ökonomisch.
Jein, für Hibernate konkret gibt es HQL sowie auch programmatische
Möglichkeiten, um programmatisch die Query zu bauen. Warum sollte man
ORM benutzen wenn man am viel Ende weniger Funktionalität hat (z.B. das
komplexe Abfragen gar nicht mehr gehen)?
>Konkretes Beispiel:
>Suche alle Autos mit dem Baujahr zwischen 2001 und 2005 ohne das Jahr 2004,
>dessen Besitzer in einem Haushalt mit mehr als 4 Personen leben. Von dem
>Ergebnis will ich pro Datensatz alle Werkstattage summiert haben, die das
>Fahrzeug in Reparatur war, wegen des Fensterheber auf der Fahrerseite. Prüfe
>ob das Fahrzeug seine Erstzulassung in einem Land mit Linksverker hatte und
>nehme die andere Seite. Verwerfe alle Ergebnisse die auf mehr als
>365Tage/Jahr kommen.
Das könnte in Hibernate auch nur so schwer sein wie die Query in SQL mit
der Hand zu schreiben.
Der Punkt an ORM ist ja gerade, dass die Mapper über Introspection
selbst wissen, was wie gejoint werden kann und muss bei einer Query. Für
den ersten Teil mit den Autos z.B. hast du eine Klasse Car mit den
Members owner und year sowie eine Klasse Owner mit Member persons. Query
ist dann sowas wie:
car.year between 2001 and 2005 and car.owner.persons > 4
ORM macht dann automatisch den Rest und zwar so, wie es für die
jeweilige DB am besten ist (in Grenzen). Beim Refactoring kann sowas zum
Beispiel wichtig sein, weil man sich um LEFT oder RIGHT JOINS statt
INNER JOIN keine Gedanken machen muss, weil das aus der
Object-Definition für ORM ableitbar ist; mit händischem SQL braucht man
gute Tests, um in solchen Fällen keine Queries zu übersehen, die evtl.
angepasst werden müssen.
>Hibernate wird das _irgendwie_ können. Aber das Ergebnis wird der Benutzer
>nicht mehr abwarten, weil der glaubt, das Programm hätte sich aufgehängt.
>(Mit Ausnahme fielleicht von Entwicklern die Eclipse-IDE benutzen. Die sind
>waren gewohnt.)
Warum? Wie kommst du zu der Behauptung wenn du dir Hibernate nur
theoretisch angesehen hast?
Sicher, Hibernate ist langsamer als handmade SQL, ist dafür aber in
Punkto Entwicklungszeit beim Schreiben/Refactoring unschlagbar im
Vergleich zu handmade.
MfG, Rocco
Mehr Informationen über die Mailingliste linux-l