Spring Praxishandbuch - Integration und Testing

5 JPA und Spring für die Modernisierung der Persistenz (S. 95-96)

Von Holger Spielmann

5.1 Java-Datenbankanbindung

5.1.1 Die Entwicklung seit den Anfängen

In jeder ernsthaften Geschäftsanwendung stand die Datenbankanbindung schon immer im Mittelpunkt des Interesses. Dass auf die Speicherung und Abfrage von Daten historisch so viel Mühe auf Java-Projekte verwendet wurde, ist dem Paradigmenbruch zwischen objektorientiertem Ansatz auf der Java-Seite und der im Regelfall auf relationaler Algebra basierten DBMS geschuldet. Objektorientierte Datenbanken werden zwar seit Beginn der 90er Jahre des vergangenen Jahrhunderts in der Informatik diskutiert. Ihre kommerziellen Ausprägungen haben sich aber wegen der Reife, Performanz und Marktdurchdringung relationaler DBMS sowie der durchgängigen Verfügbarkeit einschlägiger Fachexperten für relationale Systeme bislang nicht durchsetzen können.

Am Anfang der Java-Datenbankanbindung stand JDBC. Ohne eine weitere Persistenzschicht, die den relationalen Datenzugriff kapselt, wurde durch die Verwendung von JDBC bis zu einem gewissen Grad der relationale Aufbau nach dem Vorbild des ODBC in der C-Welt in die Anwendung übertragen. Man verlor also sehr leicht wesentliche Möglichkeiten im Design des Objektmodells, relationale Datenstrukturen dominierten die Anwendung in ihrem Aufbau. Typischerweise wurde in den Projekten der damaligen Zeit das Design einer Anwendung mit der Erstellung eines relationalen Datenmodells begonnen und dann die Java-Anwendung auf dieser einschränkenden Basis bis zur Präsentationsschicht gestaltet. Die Unhandlichkeit im Handling der konkreten relationalen Datenstrukturen, speziell das Fehlen von kollektionenwertigen Attributen und von Vererbungsmechanismen, führte dazu, dass selbst korrekt gestaltete Geschäftsobjekte im Java-Code beim Lesevorgang kompliziert zusammengeführt und beim Speichern wieder in analoger Weise explizit auf die beteiligten Tabellen verteilt werden mussten. Der Code wurde durch diese unnötigen infrastrukturellen Fragmente aufgebläht und war so entsprechend schwerer zu warten und zu erweitern.

Durch diese historische Entwicklung sind heute unzählige Java-Enterprise-Anwendungen in produktivem Betrieb, die auf diesem datenbankdominierten Design basieren und weiter gepflegt, gewartet und ggfs. auch in kleinerem Rahmen erweitert werden. Der durch das unzureichende Design entstehende, vergleichsweise hohe Aufwand bei diesen Aktivitäten lässt Betreiber solcher Anwendungen häufig nach Möglichkeiten der einfachen Umstrukturierung suchen.

Durch den vermehrten Einsatz von anspruchsvollen Enterprise-Applikationen im Web- Umfeld mit der Notwendigkeit der Modellierung komplexer Geschäftsobjekte und deren Persistenz wurde bereits Ende der 90er-Jahre offenbar, dass einfache JDBC-Mechanismen zwar zunächst die Umsetzung bestehender Legacy-Funktionen durch 1:1-Abbildung der Relationen und des beteiligten Quellcodes zum Datenzugriff erleichterten, aber die Nutzung der Vorteile echter Objektorientierung für die Wartung und Pflege großer Applikationen auf Jahre hinaus deutlich erschwerten. Aufmerksame Enterprise- Architekten begannen für große Projekte aufwändige proprietäre Persistenzschichten auf JDBC-Basis aufzubauen, die mehr oder weniger elegant die Umsetzung der relationalen Datenbankzeilen in Objektinstanzen und umgekehrt zur Weiterverarbeitung in der Applikation gewährleisten sollten. Dabei orientierte sich der Leistungsumfang dieser Persistenzschichten typischerweise nur an den jeweiligen Anforderungen der konkreten Releaseplanung für die Klientensysteme, entsprang also nicht einem generischen, werkzeugorientierten Entwurf.

Der Datenbankzugriff wurde mit den Mitteln der relationalen SQL durchgeführt, was häufig genug dazu führte, dass spezielle Eigenschaften des zugrunde liegenden DBMS ausgenutzt wurden (ob zur leichteren Formulierung von konkreten Geschäftsanforderungen oder zur Performance-Optimierung), was wiederum einen Austausch des DBMS erschwerte und damit eine Portierbarkeit, z.B. in andere Unternehmensbereiche, zu teuren Migrationsprojekten aufblähte. Viele IT-Integrationsprobleme, die bei der weltweiten Fusionswelle zum Ende der 90er-Jahre entstanden, lassen sich im Kern auf derartige, historisch gewachsene Inkompatibilitäten zurückführen, die man mit der Einführung der objektorientierten Entwicklung ursprünglich zu überwinden suchte. Erst die Vorstellung eines integrierten Enterprise-Entwicklungsmodells brachte die Hoffnung auf einen standardisierten Datenbankzugriff.