Nach dem Besuch von MySQL im Hause NETZkultur, wurden richtungsweisende Strategien für die Zukunft der Datenbank hinter infra-struktur festgelegt. Schrittweise sollen in zukünftige Entwicklungen die Data Access Objects (DAO) in infra-struktur Einzug halten. Auf der einen Seite sagen wir damit, MySQL hat die Power und die Zukunft für infra-struktur, der Ansatz stellt aber auch eine wichtige Unabhängigkeit dar. Neben einem Betrieb von Abstraktionsschichten, die einen besseren Ansatz bieten als die feste Umkodierung von SQL Syntax auf verschiedene realtionale Datenbanken, bietet der DAO Ansatz die Möglichkeit alle Vorteile von MySQL zu nutzen. Reine Abstraktion wirkt sich direkt negativ auf die Performance aus, direkte Anbindung steht negativ in Bezug zur freien Entfaltung der Entwicklung. Alle Vorteile sollen vereint werden! Bei DAOs spricht man nicht von einer Abstraktionsschicht, sondern von einem Entwurfsmuster für relationale Objekte, also einer Kapselung, sodass man die Datenquellen beliebig austauschen kann.
Bei der zukünftigen Entwicklung wird also in einem “schleichenden Prozess” die Anbindung von Datenbanken über DAOs realisiert. Alle Abfagen werden dazu in sechs Kapseln aufgeteilt:
1. Transferobjekt (in der Businesslogik wird nur noch diesen Objekten gearbeitet)
2. DAO_Factory_Interface (abstrakte Definition der Funktionalität der späteren konkreten Implementierung)
3. MySQL_DAO_Factory (die konkrete Implementierung der MySQL Sytanx mit all seinen Vorteilen)
4. Programmlogik (die infra-struktur Module, wie z.B. Anrufliste oder Mail)
5. DAO_Factory_Klasse (erstell dann die möglichen DAO Factories, MySQLDAOFactory / PDODAOFactory, einmal pro infra-struktur Instanz)
6. properties.xml (zentrale Einstellung der gewünschten Datenanbindung)
Daraus lässt sich folgendes ableiten: Man kann in den MySQL_DAO_Factories alle Vorteile von MySQL realisieren, parallel werden dann noch PDO_DAO_Factories von uns bereitgestellt. Die folgenden Treiber implementieren momentan die PDO-Schnittstelle:
| PDO_DBLIB |
FreeTDS / Microsoft SQL Server / Sybase |
| PDO_FIREBIRD |
Firebird/Interbase 6 |
| PDO_INFORMIX |
IBM Informix Dynamic Server |
| PDO_MYSQL |
MySQL 3.x/4.x |
| PDO_OCI |
Oracle Call Interface |
| PDO_ODBC |
ODBC v3 (IBM DB2, unixODBC und win32 ODBC) |
| PDO_PGSQL |
PostgreSQL |
| PDO_SQLITE |
SQLite 3 und SQLite 2 |
PHP Data Objects oder kurz PDOs stellt somit die Datenbankabstraktionsschicht bereit. Die volle Performance ist dann jederzeit über die MySQL_DAO_Factories möglich, während man mit PDOs auf andere Datenbanken ausweichen kann. Jeder kann sich selber weitere eigene DAO_Factories für seine Lieblingsdatenbank und deren Vorteile simpel selber implementieren. Benötigt wird nur das dokumentierte DAO_Factory_Interface, ein ER-Modell und vielleicht die verschiedenen MySQL_DAO_Factories Dateien als Vorlage zum Umbau. Jede Optimierung kann dann selber durchgeführt werden, auch Anbindungen von XML als Datenstruktur für infra-struktur werden damit möglich.
Alle Abfragen eines Systems werden also nicht mehr auf MySQL oder PostgreSQL gemacht, sondern es sind nur Operationen auf dem Transferobjekt (TO), völlig losgelöst von der Datenstruktur/Datenbank. Im Modul der Anrufliste findet sich also auf jeden Fall ein Transferobjekt “Anruf”, dazu gibt es noch die TOs wie Benutzer und deren Berechtigungen. Alle TOs haben also auf jeden Fall Methoden wie getXY() oder setXY().
Die Vorteile des DAO Ansatzes überwiegen also deutlich und bieten den grössten Freiraum, so ist es für uns das Konzept der Zukunft. Der Umbau wird natürlich seine Zeit dauern, nach der Freigabe der 2.9.0 ist es unser nächstes Ziel. Die Erweiterung von Features wird deshalb zugunsten von Architekturmassnahmen erstmal zurückgestellt.
————————–
http://java.sun.com/blueprints/patterns/DAO.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
