Werden heute Java-Enterprise-Anwendungen entworfen, so muss als eine der ersten Entscheidungen die Art der Persistenz geklärt werden. Diese Frage bezieht sich dabei weniger auf den Datenspeicher – ein relationales Datenbanksystem kann stillschweigend vorausgesetzt werden – sondern auf den Umgang mit den Daten. Für den Architekten ergeben sich zwei grundlegende Marschrichtungen: Fasst er die Daten der Anwendung als grobgranulare, wenig vernetzte Dateneinheiten auf, so wird er zu einem tabellengetriebenen Ansatz tendieren und vorrangig Entwurfsmuster einsetzen, die dem relationalen Aggregatzustand der Daten geschuldet sind, so beispielsweise Row/Record Sets, Page Iterators oder Data Access Objects. Sieht der Architekt hingegen die Daten der Anwendung als feingranulare, stark vernetzte Entitäten an, so ist er mit einem objektorientierten Ansatz besser beraten. Da die Daten trotz objektorientierter Sichtweise in einer relationalen Datenbank landen, gilt es hier eine Brücke zwischen beiden Welten zu schlagen. Der Unterschied, oft verharmlosend als Impedanz-Unterschied bezeichnet, ist jedoch wohl bekannt und technisch beherrschbar [1].
Als Vermittler zwischen beiden Welten existieren Frameworks, die ein objekt-relationales Mapping realisieren, ohne dass der Anwendungscode davon berührt wird. Aus Sicht des Anwendungsentwicklers handelt es sich bei dem Datenbestand der Anwendung also um einfache Objekte, die Attribute besitzen, zueinander Assoziationen eingehen oder Eigenschaften vererben. Auch das Laden, Speichern, Aktualisieren oder Sperren von Objekten geschieht ohne gesonderte Mitwirkung des Anwendungsentwicklers. Objektorientiert sind ebenso Operationen auf den persistenten Objekten oder das Suchen nach persistenten Objekten in der Datenbank. Obwohl seitens der Datenbank weiterhin alles so aussieht, als ob es nach bester ERM-Manier modelliert worden wäre.
Diese enorme Abstraktion von der Speicherform der Daten bekommt man allerdings nicht zum Nulltarif. Neben architektonischen Regeln, die eingehalten werden müssen, damit sich der Zauber der Speicher-Transparenz tatsächlich einstellt, ist ein aufwändiges, explizites Mapping von Klassen auf Relationen vorzunehmen. Der hingegen oft kolportierte Performance-Verlust bei der Verwendung besagter Mapping-Frameworks, das sei nebenbei bemerkt, ist oft mehr gefühlt als real vorhanden. Aus Sicht der Gesamtanwendung ist er fast nie nachweisbar.
Sowohl hinsichtlich des Mapping-Verfahrens als auch hinsichtlich der architektonischen Spielregeln lässt sich festhalten, dass diese gut verstanden sind. Es ist sogar möglich, diese zu katalogisieren, um so einen Kanon des O/R-Mappings aufzustellen. Zu den allgemeinen Mustern lässt sich für jedes verfügbare O/R-Mapping-Framework dann präzise die konkrete Anwendung demonstrieren. Genau diese Absicht verfolgen wir mit dem Projekt OOPEX.
