11.09.2008
Hibernate vs. IBatis – Ein Zwischenbericht
Zur Zeit sammle zum ersten mal größete Erfahrung mit dem Einsatz von iBatis. Bis vor einiger Zeit war für mich eigentlich Hibernate das Mittel der Wahl, wenn es um einen O/R Mapper ging. Mit der Einführung von EJB 3.0 war auch ein klarer Migrationsweg erkennbar, dennoch ist mein Zwischenfazit relativ positiv.
- Entwicker tun sich leichter mit SQL Statements als mit vermeintlich einfacherern (?) HQL Statements
- Man kann gezielter Statements aufrufen, es werden nur wirklich benötigte Daten geladen, was zu geringeren Resourcen verbrauch führt
- Ich kann gezielt (pro Anwendungsfall) die zu ladenden abhängigen Objekte (Relationships) definieren
- Die (erzwungene) Trennung von SQL und Java Code erhöht die Lesbarkeit
Viele dieser Sachen (gezielte Definitions von fetch clauses, Auslagern der HQL Statements) lassen sich zwar auch mit Hibernate realisieren, aber die Lernkurve bei iBatis ist deutlich flacher.
Trotzdem ist auch iBatis nicht perfekt, folgende Nachteile haben sich rauskristallisiert:
- Es muss deutlich mehr Code geschrieben werden
- Die Entwicklung muss Datenbank getrieben erfolgen, darunter leider das Objektmodell
- Änderungen am Datenmodell sind deutlich umständlicher als bei Hibernate