Pragmatisch an die Datenbank

Heute sind die meisten Datenbanken relational, die Webdienste und die damit zusammenhängenden Applikationen jedoch objekt-orientiert (OO) programmiert. Damit tun sich OO-Puristen schwer, denn Objekte passen einfach nicht so recht in die
SQL-Tabellen der relationalen Datenbanken.
Mit Werkzeugen wie JDO, Hibernate oder der jüngst angekündigten dritten J2EE-Version der Entity Beans wird zwar versucht, die Abbildung von Objekten auf relationale Tabellen (OR-
Mapping) und umgekehrt konfigurativ zu lösen.
Doch die grundlegende Problematik ist bis
heute nicht gelöst.

Eine typische mittelgrosse IT-Anwendung besteht zum Beispiel aus einer relationalen Datenbank mit 100 oder mehr Tabellen, einer EJB-Businesslogik-Schicht (Enterprise-Java-Beans) für den Persistenzzugriff auf die Datenbank und einer Webschicht mit der Applikationslogik. Die EJB-Schicht ist gemäss «Best Practice» durch eine Stateless Session Bean Facade von der Web-schicht getrennt. An der Fassade wird gleichzeitig die Transaktionsgrenze gesetzt. Optimistic Locking für die Konfliktbehandlung bei parallelen Zugriffen ist über Record-Versionierung implementiert. Abgesehen von den traditionellen Fallen des
OR-Mappings wie etwa der «N+1»-Zugriffsproblematik oder dem «Objekt-holt-Objekt-holt-Objekt»-Phänomen hält diese typische Architekur weitere Stolpersteine bereit. Zum einen finden wir ein Business-Objektmodell in den Sessions der Webschicht. Ist die EJB-Schicht stateless, macht dort ein OO-Modell wenig Sinn, da dessen Lebenszeit jeweils auf die Dauer der Transaktion beschränkt ist. Aufgrund der Transaktionsgrenze ist das Objektmodell in den applikatorischen Sessions nicht direkt über den OR-Mapper mit der Datenbank verbindbar. Zum andern macht es der
Optimistic-Locking-Ansatz schwierig, die Tabellenstruktur vor der Applikation zu verbergen, da wegen der Versionierung der Record immer durchbricht.

In der Tat drängt sich hiermit eine Selbstbeschränkung auf. Datenbankeinträge werden eins zu eins auf Java-Datenobjekte abgebildet, die Transaktionslogik von Hand kodiert und diese Datenobjekte zwischen EJB- und Web-Schicht hin- und her geschoben. Dieser Ansatz mag vielen OO-Adepten zu einfach erscheinen, doch in der Praxis erfolgt die Bewirtschaftung einer Datenbank zu 90 Prozent durch eine einzige Applikation. Diese Applikation ist so stark an die Datenbank gekoppelt, dass sich jede Datenbankänderung mit hoher Wahrscheinlichkeit in der Applikation niederschlägt. Schliesslich wird auf einer Maske nicht viel mehr angezeigt als ein Record oder eine Trefferliste aus einer View. Statt generisch zu operieren, darf das Objektmodell in der Applikation durchaus Tabellen und Views aus der Datenbank widerspiegeln.

Allerdings erlauben es ORM-Frameworks bis heute nicht, beliebige Objektmodelle performant mit beliebigen Datenbankmodellen zu koppeln. Die Entwicklung wird in diesem Bereich sicher weitergehen. Wer aber heute einen Persistenzzugriff entwirft, muss sich der technischen Limitierungen bewusst sein. Ein Datenbank-nah entworfenes Objektmodell erlaubt es, sich bei OR-Werkzeugen auf die zentralen Eigenschaften zu beschränken. Man ist entsprechend weniger abhängig von Entwicklungen in diesem Bereich und kommt effizient mit Pragmatismus zum Ziel.