Bei einer Diskussion mit einem Kollegen wurde ich gefragt: “Worin besteht der Unterschied zwischen SDO und DAO?” Ich hatte nicht sofort eine prägnante und zufriedenstellende Antwort parat. So beschloss ich etwas ausführlicher darüber nachzudenken:
Liest man die Java Blueprints von Sun zum DAO Pattern und den JSR-235 für SDO, so erkennt man ein gemeinsames Ziel:
Sowohl das DAO Pattern als auch die SDO Spezifikation zielen auf die Entkopplung der Geschäfts- von der Persistenzlogik und bitten eine API für einen einheitlichen Zugriff auf Daten über verschiedene heterogene Datenspeicher wie Datenbank oder XML.
Es gibt jedoch auch signifikante Unterschiede:
- DAO ist ein Design Pattern und die Entwickler müssen bei jedem Projekt die DAO Klassen manuell neu programmieren. Zwar gibt es auch diverse DAO Frameworks wie z.B. iBatis, die API und die Handhabung sind im Gegensatz zu SDO je nach Framework jedoch immer etwas unterschiedlich. Die Entwickler müssen also bei jedem neuen Projekt das jeweils eingesetzten Framework und dessen Eigenheiten neu lernen. SDO dagegen ist eine Spezifikation und ermöglicht es verschiedenen Herstellern standardkompatible Werkzeuge und Frameworks mit einer gemeinsamen API zu entwickeln. Der Entwickler kann darauf vertrauen, dass unabhängig vom tatsächlich eingesetzten Produkt die API und Handlung gleich bleibt. Auf diese Weise wird der Lernaufwand für Entwickler und damit auch die Entwicklungszeit und -kosten reduziert.
- SDO bittet eine Möglichkeit einen Daten Graph ohne direkte Verbindung zur Datenquelle zwischen verschiedenen Schichten bzw. Services auszutauschen, zu modifizieren und später wieder zurück zum Daten Access Service, wo die Änderungen auf den Datenspeicher angewendet werden, zu schicken. Das DAO Design Pattern deckt diese Anforderungen nicht ab.
- SDO spezifiziert wie eine statische, fest typisierte API aus einem Schema generiert werden kann und stellt auch eine dynamische API bereit. Der Anwender hat hier die Wahl wie er auf den Datenspeicher zugreifen möchte und kann auch beide Varianten in einer Anwendung einsetzen. DAO bittet keine dynamische Zugriffsmöglichkeit und der Entwickler ist daher gezwungen auf die Low-Level API wie JDBC zurückzugreifen wenn dynamische Zugriffe erforderlich sind.
- SDO ist für den Einsatz in einer Service orientierten Architektur ausgelegt und definiert Datentypen um die Portabilität zwischen den verschiedenen Datenspeicher und unterschiedlichen Programmiersprachen zu gewährleisten. Zum jetzigen Zeitpunkt gibt es Implementierungen für Java, C++ und PHP. Das DAO Pattern dagegen adressiert diese Problematik nicht.
Die interessantere Frage ist jedoch wann sollte DAO und in welchen Fällen SDO verwendet werden:
DAO ist eine hervorragende Wahl um die Persistenzschicht und die eingesetzten Technologien wie z.B. JDBC, EJB CMP oder Hibernate zu abstrahieren und somit den Code für den Datenzugriff vom Rest der Anwendung zu isolieren.
SDO eignet sich ausgezeichnet für Anwendungen, die in einer Service orientierten Architektur eingesetzt werden, wenn in der Umgebung unterschiedliche Programmiersprachen eingesetzt werden und Daten ohne direkte Verbindung mit der Datenquelle zwischen den Services ausgetauscht werden müssen.
Ähnliche Artikel:
Letzte Kommentare