JM 3/2007 Muskelspiele

[B. Müller]

auf Seite 3 wird iBATIS mit "Durch seine Einfachheit unterscheidet sich das iBATIS Data Mapper Framework Object von relationalen Mapping-Tools" eingeführt.

Auf Seite 19 wird in Listing 1 die Grundlage von iBATIS für die einfachsten CRUD-Operationen

• Objekt über Primärschlüssel lesen
• Alle Objekte lesen
• Objekt speichern
• Objekt aktualisieren

angegeben. Bis auf die zweite Operation sind diese Operationen in JPA und Hibernate standardmäßig vorhanden. KEIN zusätzlicher Aufwand. Die zweite Operation wird in der Praxis nicht häufig eingesetzt werden, da man sich in der Regel keine 5 Millionen Objekte in die JVM holen will. Falls doch, erreicht man es mit einer Query der Art "from Benutzer". Das ist schon alles.

Listing 1 entfällt also praktisch ganz. Listing 2 bleibt, was den Umfang angeht,
praktisch identisch. Die Konfiguration (DBMS, Verbindungs-URL, Authentifizierungsdaten) ist bei beiden Alternativen notwendig.

Unter dem Strich bleibt die Tatsache, dass das Beispiel über iBATIS nicht zeigt, dass iBATIS einfacher als JPA/Hibernate ist, sondern das Gegenteil.

B. Müller

[MichaelPloed]

Hallo Herr Müller,
vielen Dank für Ihr Feedback auf meinen Artikel.

Ihr Kritikpunkt bzgl. der Einfachheit ist für das gewählte Beispiel korrekt, das kann man mit Hibernate oder wirklich einfach hinbekommen. Ich wollte in dem Artikel jedoch Alternativen für Projekte aufzeigen, für die ORM nicht zwingend die einfachste Wahl ist. Ein komplexes Beispiel hätte den Rahmen des Artikels leider gesprengt (ich wollte für jedes Tool das gleiche Beispiel verwenden). Ich sehe dort primär zwei Szenarien (gesetzt dem Fall, dass die Anzahl der abzubildenden Tabellen überschaubar ist):

1) Integration einer Legacy Datenbank, die nicht "sauber" entworfen ist und bei der sich das Domänen Modell in der Java Anwendung stark vom ER Modell der Datenbank unterscheidet.

2) Teams, in denen wenig Erfahrung mit OR Mappern besteht. Hier läuft man häufig Gefahr, dass zum einen die API falsch verwendet wird (ich denke hier spontan an die Unterschiede zwischen Hibernate merge() und saveOrUpdate()). Des Weiteren "verlaufen" sich unerfahrene Entwickler in Query und Mapping Optionen, die bei komplexen Datenbanken manchmal nicht trivial sind.

In beiden Szenarien habe ich es häufig erlebt, dass Entwickler zu mir kommen und sagen "Michael, ich will, dass folgende SQLs gegen die Datenbank gehen, wie krieg ich das mit Hibernate hin". Oder "Michael, ich bekomm ständig eine 'An Object with the same ID is already bound to the session' Exception, ich glaub da ist ein Bug in Hibernate". Auch das Thema Detach / Re-Attach ist in verteilten Architekturen auch nicht unbedingt trivial. Ich denke, dass in solchen Fällen iBATIS die einfachere Wahl ist.

Trotzdem stimme ich Ihnen natürlich zu: Bewegt man sich in einem Umfeld, welches für ORM geeignet ist, dann sind Hibernate und JPA mich Sicherheit eine gute Wahl. Wobei man sich immer im klaren sein muss: ORM ist nie eine 100%- , sondern eher eine 75 - 90 % Lösung. Vor diesem Hintergrund fand ich den Blog von Ted Neward sehr lesenswert.

Ich persönlich denke, dass folgende Herangehensweise sinnvoll ist:

Hat das Team Erfahrung mit ORM und kennt es dessen Grenzen würde ich auch bei einfachen und komplexen Datenbanken Hibernate (auch als JPA Provider) verwenden und für Sonderfälle Native SQL , iBATIS oder das JdbcTemplate verwenden.

Besteht nur wenig Erfahrung mit ORM und sind die Grenzen nicht bekannt würde ich mir überlegen, ORM einzusetzen oder anfangs für einfache Tabellen / Relationen auf ORM zu setzen und dann "Experten" im Team aufbauen, die sich entsprechendes Wissen aneignen und dieses dann auch verbreiten.

Viele Grüße,
Michael Plöd