Entwickelt man Applikationen auf modernen objektorientierten Plattformen wie Java, so stellt sich oft die Frage, wie man Objekte sauber persistiert. Häufig wird man auf den Komfort und die Leistungsfähigkeit, die relationale Datenbanken unter anderem in bezug auf Abfragen, Transaktionen und Backup bieten, nicht verzichten wollen. Nun existiert mit JDBC in Java ein standardisiertes Interface zum Zugriff auf relationale Datenbanken. Die «direkte» Verwendung von JDBC hat jedoch in der Praxis viele Nachteile:
- Java-Code und SQL-Statements sind üblicherweise vermischt oder lassen sich nur schwer voneinander trennen.
Meist wird daher bei modernen Anwendungen ein objektrelationales (O/R) Mapping-Tool eingesetzt, das die Verbindung zwischen Objekten, die persistiert werden sollen, und der Datenbank herstellt. Es gibt hier unzählige Frameworks, beispielsweise Hibernate, Castor, OJB und Toplink.
Dennoch sind diese Frameworks nicht uneingeschränkt zu empfehlen. Hibernate & Co. erlauben, detaillierte Abbildungen von Objekthierarchien auf Tabellen in einer relationalen Datenbank zu definieren. Der Entwickler arbeitet dann nur mehr auf Objektebene und bekommt sogar eigene Abfragesprachen wie HQL zur Verfügung gestellt. Die konkreten SQL-Statements, die für den Zugriff benötigt werden, werden vom Framework je nach verwendeter Datenbank automatisch generiert.
Weiter bieten diese Frameworks typischerweise vollen Roundtrip-Support an. So kann man die Mappings in Java-Annotationen deklarieren und dann die konkreten Mapping-XML-Dateien sowie die Datenbank generieren lassen.
Diese Abstraktion ist in vielen Fällen sehr nützlich und leistungsfähig, birgt aber auch verschiedene Nachteile sowie Risiken: Die Verwendung von Frameworks wie Hibernate ist in der Praxis ziemlich komplex, die Einarbeitungszeit entsprechend hoch. Man muss die Mapping-Definitionen verstehen, die neue Abfragesprache, die Tools sowie die vielen Konfigurationsmöglichkeiten wie Caching. All dies kann sehr aufwendig sein, besonders dann, wenn Code-Generierung verwendet wird. Dies ist eigentlich fast immer anzuraten, weil sonst die Gefahr besteht, dass verschiedene Teile der Anwendung ausser Synchronität geraten.
Frameworks wie Hibernate sind daher vor allem in grossen und komplexen Projekten angeraten, wenn auch ein entsprechender Experte des jeweiligen Frameworks zur Verfügung steht.
iBatis hingegen geht einen anderen Weg. Bruce Tate beschreibt es in seinem Buch «Spring Developers Notebook» so: «iBatis ist ein JDBC unterstützendes Framework, das viele Vorteile von O/R-Mappern bringt, aber nicht deren Risiken mitbringt.» iBatis ist eigentlich auch kein O/R Mapping Framework, vielmehr werden anstelle von Tabellen SQL-Statements auf Objekte gemappt. Das heisst, SQL ist ein zentraler Bestandteil von iBatis-Anwendungen, allerdings werden diese sauber vom Java-Code über XML-Maps getrennt.
Dies hat klare Vor- und Nachteile: Einerseits hat man die volle Leistungsfähigkeit von handoptimiertem SQL zur Verfügung, was bei Hibernate nur «durch die Hintertür» möglich ist. Gleichzeitig ist damit natürlich die Bindung an eine konkrete Datenbank auch höher, was aber in vielen Anwendungsfällen unproblematisch ist. Das Unterstützen einer weiteren Datenbank bedeutet, dass neue Mappings erstellt werden müssen, wozu allerdings kein Eingriff in den Java-Code notwendig ist. Auch Stored Procedures werden besser unterstützt. Bei einem niedrigeren Grad an Abstraktion macht dieser Zugang das Mapping natürlich wesentlich einfacher.
iBatis benötigt eine Konfigurationsdatei (sqlMap-config.xml), in der die wesentlichen Optionen für den Datenbankzugriff deklariert werden. Dazu gehört die Konfiguration der verwendeten Datenquelle (z.B. ein Connection Pool), eines eventuell verwendeten Transaktionsmanagers sowie die Definition der eigentlichen SQL-Map.
Der Kern einer Applikation mit iBatis ist nun die Beschreibung der Mappings (siehe auch Abbildung 1). Im wesentlichen wird für jedes zu persistierende Objekt eine SQL-Map erstellt. In dieser Map können für dieses Objekt verschiedene Operationen definiert werden wie «Insert», «Update» oder «Get» Jede dieser Operationen wird durch ein beliebiges SQL-Statement beschrieben. Das heisst, das Objekt wird an verschiedene SQL-Statements gebunden, und diese entscheiden dann, welche Tabellen für die Abarbeitung verwendet werden.
Dies lässt sich am besten mit einem Beispiel illustrieren: Soll das Objekt «Person» (mit nachname, vorname, email) in die Datenbanktabelle «PERSON» gespeichert werden, so ist ein Mapping zu definieren, das die Übergabeparameter aus dem Objekt übernimmt und ein INSERTStatement formuliert, das an die Tabelle angepasst ist. Es könnte etwa so aussehen:
insert id=“insertPers“ parameterClass=“ch.infoweek.example.Pers“>
INSERT INTO PERSON (
FIRST_NAME, LAST_NAME,
EMAIL
) VALUES (
#vorname#, #nachname#,
#email#
)
/insert
Neben den genannten Funktionen bietet iBatis weiter eine DAO-Bibliothek an. Diese ist optional und muss nicht verwendet werden. Jedoch empfiehlt es sich in jedem Fall, das DAO-Enterprise-Pattern für eigene Anwendungen einzusetzen – egal, ob man nun die iBatis-Bibliothek verwendet oder es selber implementiert.
Der Grundgedanke des DAO-Pattern ist in Abbildung 2 illustriert. Wesentlich ist hier, dass Zugriff auf Persistenz-Mechanismen nur von ausgewählten Klassen, den DAOs, erfolgt und nicht quer über die Anwendung verteilt mit Persistenz-Klassen wie den SQL-Maps interagiert wird. Praktisch bedeutet dies folgendes:
- Man definiert ein Interface, in dem in neutraler Weise Zugriffsmethoden definiert sind; diese sind unabhängig vom verwendeten Persistenz-Mechanismus.
- Man implementiert konkrete DAOs, beispielsweise für iBatis, für XML oder für Hibernate, je nachdem, was benötigt wird.
- In den «Geschäftsobjekten» arbeitet man ausschliesslich mit Variablen vom Interface-Typ und holt sich die konkrete DAO-Instanz von einem Container wie Spring.
- Ein Transfer-Objekt (ein normales Java-Bean) wird verwendet, um Daten auszutauschen.
Der grosse Vorteil dieses Ansatzes ist es, dass jederzeit der Persistenz-Mechanismus ausgetauscht werden kann – von iBatis auf XML oder auf Hibernate –, ohne dass die Business-Logik verändert werden muss: Man muss «nur» neue DAOs implementieren und die Konfiguration des Containers ändern.
Abbildung 2: Aufbau des DAO-Patterns
Der Einstieg in iBatis sollte nicht allzu schwerfallen. Einerseits, weil das Konzept leicht verständlich ist, andererseits aber auch, weil die Dokumentation sehr gut ist.
Es existieren ein kurzes Tutorial, das auf wenigen Seiten die Prinzipien mit Code-Beispielen erklärt, ein umfangreicheres Handbuch sowie eine Beschreibung der Data-Access-Object-Bibliothek. Parallel dazu gibt es umfangreiche Sekundärliteratur wie «iBatis in Action» (ISBN 1-93239-482-6) oder «Spring, a Developer’s Notebook» (ISBN 0-596-00910-0) von Bruce Tate.
iBatis wird weiter (ebenso wie Hibernate, Castor und OJB) vom Framework Spring unterstützt, das heisst, man kann sehr einfach die bekannten Spring-Mechanismen zur Konfiguration (Dependency Injection) sowie deklarative Transaktionen und Templates nutzen.
Neben Java existieren auch Portierungen für .Net und Ruby. Spezifische Datenbank-Klassen sind nicht erforderlich, da ja beliebige JDBC-Treiber sowie SQL-Statements verwendet werden können. Daher sollte iBatis mit allen bekannten relationalen Datenbanken funktionieren.
iBatis ist empfehlenswert, wenn:
· volle O/R-Funktionalität nicht unbedingt erforderlich ist und man ein sehr schnell zu erlernendes und dennoch leistungsfähiges Framework verwenden möchte.
· bestehende Datenbanken integriert werden sollen.
· Datenbank- und Anwendungsentwicklung getrennt sind.
· volle Leistungsfähigkeit von optimierten SQL-Statements genutzt werden soll.
· das Datenmodell eher einfach ist.
· kein gut geschulter Hibernate-Experte vor Ort ist.
iBatis ist hingegen weniger geeignet, wenn:
· das Datenmodell komplex ist (Vererbungen etc.)
· von SQL abstrahiert werden soll (einfache Unterstützung verschiedener Datenbanken)
· Erstellen von Datenbank-Metadaten und Mappings automatisiert werden soll (Codegenerierung)
Alexander Schatten (alexander@Schatten.info) ist Assistent am Institut für Softwaretechnik und Interaktive Systeme der Technischen Universität Wien.
