J and I and Me
2007-09-24
  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:

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:

  14:21
Bookmark and Share
Comments:
tod oder tot? Erich oder Eric?
 
Ein DAO muss ja auch nicht immer Datenbankzugriffe verbergen. Es heißt ja auch DATA Access Object und nicht DATABASE Access Object. Spring bietet ja z.B. eine CciDaoSupport. Denkbar wären auch andere Persistenzmechanismen: XML Files, Binaries etc. Von daher stellt sich die Frage nicht wirklich, denke ich.

Gruß
Ollie
 
In meinen Augen ist das DAO nicht tot. Ich verwende DAOs sehr gerne um Projekt Standards im Bereich der Persistenz zu etablieren (zb. Hibernate saveOrUpdate vs. merge).
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff