Data Mapper Pattern

Ein typisches Dilemma

Bei der Entwicklung einer Anwendung mit einer Datenbankanbindung steht man vor dem Dilemma, dass die Strukturierung der Daten im Datenbankschema sich von der der Domain-Logik der Anwendung unterscheidet. Beispielsweise fehlen in relationalen Datenbanken Strukturen wie Collections oder Vererbung, die jedoch in der Anwendung Verwendung finden, um Objekte zu strukturieren. Besonders bei der Entwicklung im Team ist es vorteilhaft, ein Objektmodell inkrementell und unabhängig von der Datenbank zu entwickeln und das Datenbankmodell auf spätere Phasen zu verlagern. Ferner erweisen sich Operationen in persistenten Datensätzen als teuer, da diese eine Verbindung zu der Datenbank erfordern.

Datenstruktur und Objekt – eine gelungene Trennung

Die Trennung zwischen Datenstruktur in der Datenbank und dem Objekt der Anwendung bietet sich durch das „Data Mapper Pattern“ an. Das Data Mapper Muster gehört zu der Kategorie der „Architectural Patterns“, den Architekturmustern und stellt eine Schnittstelle zur Datenbank, mit den renommierten CRUD-Funktionen Create, Read, Update und Delete, zur Verfügung. Damit wird eine bidirektionale Verbindung zwischen persistenten Datenbeständen (Datenbank) und der Laufzeitdaten hergestellt.

Martin Fowler

Martin Fowler beschreibt dieses Muster als eine Ebene von Abbildungen, die Daten zwischen Objekten und Datenbanken bewegen. Dabei bleiben die beteiligten Parteien und der Mapper selbst unabhängig:

A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself.

– Martin Fowler (Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002.)

Das Data Mapper Pattern wird besonders häufig in Webanwendungen verwendet. Für PHP bietet sich mit Doctrine ein starker Datenbank-Abstraktionslayer an. Mit Hilfe des objektorientierten SQL Dialekts (Doctrine Query Language [DQL]), steht dem Entwickler eine Alternative zur standardmäßigen Ausführung von SQL bereit. Dadurch lassen sich Flexibilitätsvorteile erlangen, da unnötige Codeduplikate und damit verbundene Datenbankverbindungen vermieden werden.

Umsetzung

Die nachfolgende Grafik zeigt an dem Beispielobjekt Person, wie das Pattern funktioniert.

Data Mapper Pattern – Das Zusammenspiel von Objekt, Mapper und Datenbank.

 

 

 

1. Person

Zuerst wird das Objektmodell entwickelt, ehe die Datenbankmodellierung ansteht. Somit wird im ersten Schritt das Person-Objekt entworfen und danach implementiert. Um es beim Einfachen zu belassen bekommt eine Person einen Vor- und Nachnamen, den man sowohl eingeben als auch ausgeben kann.

2. Person Mapper

In unserem Beispiel übernimmt der Mapper die Aufgabe, neue oder bearbeitete Objekte in die Datenbank zu speichern oder aus der Datenbank zu löschen.

An dieser Stelle sind die Methoden nicht implementiert. Praktisch ist nämlich, dass jede SQL-Datenbank benutzt werden kann. Wichtig ist aber, dass ein Person-Objekt übergeben wird. Selbstverständlich kann der PersonMapper erweitert werden, um eine Person oder eine Menge an Personen aus der Datenbank zu holen.

3. Person Tabelle

Zu guter Letzt wird auf der Basis des Objektmodells die Datenbanktabelle angelegt.

Die Person-Tabelle enthält einen Vor- und Nachnamen mit bis zu jeweils 65 Zeichen.

 

 

 

@Tutorial

Zu diesem Thema gibt es in Zukunft ein Tutorial, das auf Doctrine basiert. 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.