O/R-Mapper und Alternativen

Fallstudien  –  Kommentare
Aufmacher

Objektrelationale Mapping-Frameworks gehören zum Repertoire der Softwareentwicklung, wenn es um die Anbindung relationaler Datenbanken an objektorientierte Programme geht. Nicht immer jedoch sind sie das beste Werkzeug für diese Aufgabe.

Wer die Debatten der Persistenz-Szene der letzten Jahre verfolgte, konnte den Eindruck gewinnen, O/R-Mapping-Frameworks wie Hibernate und Castor lösten die Persistierungsaufgabe und überwänden alle Hürden zwischen objektorientierter Entwicklung und relationalen Datenbanken automatisch und kinderleicht. Mittlerweile werden aber die Stimmen lauter, die bezweifeln, mit Hibernate-Kenntnissen aus einem zweiseitigen „Getting-Started“-Tutorial und ein paar Mapping Annotations hätte man die Persistenz jeder Java-Anwendung sofort im Griff. Eine gründliche Betrachtung, welche Werkzeuge und Architekturen sich wann sinnvoll einsetzen lassen, ist angezeigt.

Sollen Objekte die Ausführung des Programms überdauern, muss man die Unterschiede zwischen ihrer Welt und der relationaler Datenbanken überbrücken. Zugriffe über einfache Protokolle wie JDBC waren lange Zeit der übliche Weg. Allerdings muss bei ihnen der Entwickler den Datenaustausch zwischen Objekten und Tabellen selbst programmieren. Dies ist mühsam und führt oft zu schwer wartbarem Code, häufig wegen der Vermischung von SQL- und OO-Statements.

Seit einigen Jahren versprechen O/R-Mapping-Frameworks (zu den bekannteren zählen Hibernate und Castor), diese Verbindung einfacher und eleganter herzustellen und damit von der relationalen Datenbank sauber zu abstrahieren. In vielen Projekten können diese Werkzeuge gute Dienste leisten, performant sein und Vorteile in der Softwareentwicklung bringen. Sie bergen aber andererseits Risiken, derer man sich bewusst sein sollte. Dies gilt vor allem, wenn weniger erfahrene Entwickler oder Teams O/R-Mapper einsetzen.