Design Patterns für Datenbankzugriff

Seit die als "Gang of Four" bekannte Gruppe von Software-Entwicklern das Standardwerk "Design Patterns - Elements of Reusable Object-Oriented Software" veröffentlichte, sind mehr als zehn Jahre vergangen [1]. Heute sind die von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides beschriebenen Entwurfsmuster in der Entwicklungspraxis nicht mehr wegzudenken.

Die Erkenntnis, dass beim Code-Entwurf bestimmte Zusammenhänge immer wieder auftauchen, gehört nun zum Standardwissen. Denn Software will nicht nur für einen bestimmten Zweck entwickelt werden, sondern soll auch eine ganze Reihe von Nebenbedingungen erfüllen. Eine der fast immer anzutreffenden Bedingungen ist der berechtigte Wunsch der Software-Architekten, dass Code wiederverwendbar, also möglichst leicht verständlich sein soll. Funktionalität allein ist schon seit längerem nicht das einzige Nonplusultra einer guten Software. Sie muss leicht anpassbar, erweiterbar und robust sein.

Datenbank-Muster

Die Gang of Four hat in ihrem Buch ganze 23 Design Patterns ausfindig gemacht und sie in verschiedenen Kategorien zusammengefasst. Darunter fallen unter anderem Patterns, die die Mensch-Maschine-Interaktion strukturieren oder Komplexität verbergen, oder Patterns, die gewährleisten, dass eine Sitzung bestimmte Code-Abschnitte nicht mehrmals ausführt. Als realistischer Anwendungsfall dient im Folgenden die Kommunikation eines Users mit einer für ihn verborgenen Datenbankinstanz. Bei der Implementierung kommen Mono 1.2 und C# zum Einsatz.

Als die Softwarewelt noch übersichtlich war und es einige wenige Hersteller von Datenbank-Standardsystemen gab, fiel die Wahl der geeigneten Plattform wesentlich leichter, als es heute der Fall ist. In einer schnelllebigen Welt wie der Softwarebranche machen neue Datenbanksysteme alten Hasen das Leben immer schwerer. Von MySQL bis zu den rein objektorientierten Systemen wie Db4o ist die Auswahl heute riesig.

Fassade

Da nur wenige Firmen den Wunsch hegen, ihre alten Datenbestände komplett auf neue Plattformen zu hieven, stellt sich ihnen oft die Frage: Wie behalten wir alte Daten, ohne auf neue Technologien verzichten zu müssen? Mit einem passenden Design Pattern lässt sich eine solche Aufgabe meistern. Am besten gestalten Programmierer den Zugriff auf alte und neue Datenbestände von Anfang an transparent, da es für die Verarbeitung der gewonnen Daten unerheblich ist, woher sie stammen und wie das darunter liegende Datenbanksystem im Detail aufgebaut ist.

Das dazu am besten passende Pattern ist Facade [2]. Wie eine Hausfassade bietet es von außen gesehen eine einheitliche Oberfläche, hinter der sich ganz unterschiedlich eingerichtete Zimmer verbergen. Das folgende Beispiel implementiert einen transparenten Zugriff auf eine MySQL- und eine Oracle-Datenbank, bei dem sich der Benutzer nicht darum kümmern muss, manuell eine Datenbankverbindung aufzubauen. Vielmehr gibt es eine gemeinsame Schnittstelle, die SQL-Befehle weiterleitet und Daten zurückliefert.

Abbildung 1 zeigt den Aufbau der implementierten Architektur. Sie verbirgt in Form einer übergeordneten Klasse zwei weitere Klassen, die auf bestimmte Datenbanksysteme spezialisiert sind. Die Oracle-Express-Datenbank (Oracle XE) können Debian-Benutzer über das Non-Free-Repository beziehen. Anwender anderer Distributionen laden es am besten von der Oracle-Homepage herunter [3]. Als Datenbank-Treiber für MySQL dient entweder der nicht weiterentwickelte Bytefx-Treiber, der Teil des Mono-Framework ist, oder der MySQL-Connector des Herstellers.

Abbildung 1: Das Facade-Pattern verbirgt die beiden darunter liegenden Datenbanksysteme. Für den Client ist der Zugriff abstrakt.