DAO tot?
Es gibt
hier eine Diskussion, ob das DAO tod ist. Die Argumentation läuft darauf hinaus, dass das ursprüngliche J2EE-DAO-Pattern das Ziel hatte, die Unterschiede zwischen verschiedenen Persistenz-Technologien zu verbergen. Die Argumentation ist nun, dass mit JPA die API geschaffen wurde, die so mächtig ist, dass man die unterschiedlichen Technologien nicht mehr verstecken muss. Dazu kann man technisch erstmal einwenden, dass JPA beispielsweise gegenüber Hibernate ein Rückschritt ist, denn wichtige Features wie Filter oder UserTypes existieren nicht - aber auch weniger wichtige Features wie die Criteria API sind nicht vorhanden. Ich würde daher argumentiere, dass man mit JPA nicht weit genug kommt und man sich nicht nur auf diese Technologie verlassen kann - also hat das DAO seinen Sinn schon technisch nicht unbedingt verloren.
Noch interessanter ist diese Aussage vor dem Hintergrund der Architektur. DAOs sind eben nur eine Möglichkeit, auf eine Datenbank zuzugreifen. Wenn man Fowler's Buch "Paterns of Enterprise Application Architecture" zu Rate zieht, findet man zahlreiche Alternativen, von denen hier einige genannt seien:
- Transaction Script implementiert die Datenbank-Anfragen direkt in den Services.
- Active Record implementiert die Persistenz direkt im fachlichen Objekt.
- Table Module implementiert für jede Tabelle eine Klasse.
- Der Mapper, der die Daten aus der Datenbank in Instanzen des Domain Models überführt - DAOs würde ich am ehesten als Implementierung dieses Patterns sehen.
WIe man sieht, ist das DAO nicht alleine auf der Welt. Daher stand es schon immer in Konkurrenz zu anderen Ansätzen. Der Griff zum DAO ist also eine Design-Entscheidung - die allerdings manchmal eher einem Reflex als einer Entscheidung zu entstammen scheint.
Ich würde allerdings argumentieren, dass die Implementierung einer Persistenz-Schicht nach dem DAO-Paradigma oft sehr sinnvoll ist. Besonders interessant ist in diesem Zusammenhand Eric Evans Buch über Domain Driven Design. Das Buch steht nicht im Verdacht, technik-zentriert zu sein. Also sollte es sich nicht dadurch beeindrucken lassen, dass es nun mit JPA eine neue Technologie hibt. Dennoch führt es aus, dass man im Design einer Anwendung ein Repository einführen kann. Das Repository ist ein Zugang zu den Objekten, die bereits existieren, im Gegensatz zu einer Factory, die neue Objekte erzeugen soll. Es kann Daten aus einer Datenbank oder aus einem Legacy-Anwendung auslesen und daraus Objekte erzeugen. Damit ergibt sich schon aus fachlichen Gründen der Bedarf nach einer Art DAO, das den Zugriff auf die persistenten Daten ermöglicht. Meinem Gefühl nach legt das Repository den Akzent vor allem auf fachlich motivierte Anfragen, während viele der Funktionalitäten des DAOs eher einfache Operationen wie Speichern umfasst.
Ein weiterer guter Grund für DAOs oder zumindest eine separierte Persistenz ist, dass man damit die Anwendung sehr leicht testen kann - man kann sehr leicht statt dem eigentlichen DAO in einem Test etwas verwenden, was bestimmte Testdaten zurückgibt. Das funktioniert dann ohne Datenbank und die üblichen Schwierigkeiten beim Testen mit Datenbank - Aufbau der Datenbank, Bilden von Testdaten und Aufräumen der Datenbank nach dem Test.
Vielleicht ist ein Grund für die Verwirrung das ein DAO eben nicht in erster Linie eine einfachere Migration von einer Persistenz-Technologie zu einer anderen erlaubt, sondern andere Vorzüge hat. Ich halte es jedenfalls immer noch für eine gute Idee, wenn man auch mit dem Begriff Repository vielleicht weiter kommt.
Ein letzter Hinweis: Vielleicht ist die Diskussion doch technisch begründet. Immerhin kann EJB 3 einen EntityManager nur in eine Session Bean injizieren. Damit hat man nur die Wahl die DAOs also Sessions Beans zu implementieren oder den EntityManager per Hand in die DAOs zu injizieren oder dort auf Dependency Injection zu verzichten. Vielleicht erscheint daher bei EJB 3 ein Ansatz ohne DAOs erstmal eleganter. Spring ermöglicht DI eines EntityManagers für jede Spring-Bean und verwendet dabei die in JSR 220 standardisierte @PersistenceContext-Annotation.
Labels: DAO