Ich fand JPA, oder ähnlich, ermutigen nicht DAO-Muster

Question

Ich fand JPA, oder ähnliche, ermutigen nicht DAO-Muster. Ich weiß es nicht, aber ich fühle mich so, besonders mit serververwalteten JTA-Managern.

Nachdem ich mich mit DAO-Mustern beschäftigt hatte, begann ich, JPA-basierte Anwendungen nach diesem Muster zu gestalten. Aber es passt nicht hinein, IMO. Ich neige dazu, ziemlich Eigenschaften von JPA und allem zu verlieren.

Nun, nehmen wir an, Sie feuern eine Abfrage mit pessimistischem Locking und es wurde eine Liste von enites von einer DAO-Methode zurückgegeben. Nach der Rückgabe endet die Transaktion und die Sperre ist aufgehoben (ein Fall mit dem vom Server verwalteten JTA-Manager). Also, sinnlos. Es gibt jedoch gültige Fälle.

Ein anderes Beispiel ist viel trivialer. Angenommen, Sie führen eine Abfrage aus, um eine Entität abzurufen, die eine lau- fende Eins-zu-Viele-Verknüpfung mit einer anderen Entität hat. Nach dem Zurückgeben der DAO-Methode endet die Transaktion. Lazy Loading würde nicht mehr funktionieren, Sie erhalten einfach null oder so. Um das zu bewältigen, laden wir es gerne manuell. Wir machen etwas wie a.getBList().size().

Also IMO ist es besser, nicht ein DAO ausschließlich zu machen, und tun Sie es in Ihrem Business-Bean, auf diese Weise können Sie diese nützlichen Funktionen nutzen. Oder ORM API kann wohl als eine DAO/Datenschicht selbst angesehen werden. Also müssen wir kein anderes machen.

Was denken Sie darüber?

Hinweis: Ich sage auf keinen Fall, dass das DAO-Muster veraltet ist. In der Tat hängt es von Fall zu Fall ab.

Answer 1

Für einfache Anwendungen sehe ich kein Problem bei der Verwendung der EntityManager direkt von EJBs und überspringe das DAO-Muster (ich bin es leid, zu viel Code zu schreiben). Und ich habe das Gefühl, dass JPA und die Java EE API dies fördern.Aber es kann immer noch für komplexere Anwendungen (für den Datenzugriff von gespeicherten Prozedur, flache Dateien ...) gerechtfertigt sein. Also hast du recht, es kommt darauf an :)

Sie finden andere erleuchtete Standpunkte in Has JPA Killed the DAO? auf InfoQ, aber Sie werden nicht durch den Inhalt und die Schlussfolgerung überrascht sein, die wie folgt zusammengefasst werden können: Sie nicht wirklich brauchen das DAO-Muster für den Standard-Datenzugriff, Sie können es jedoch für einige komplexere Situationen benötigen, aber wir leben besser ohne es.

Answer 2

Wenn Sie das DAO nicht als transaktional definieren, haben Sie diese Probleme nicht.

Die Serviceebene sollte transaktional sein, da sich eine Transaktion über mehrere Operationen erstrecken soll. Es ist nicht das beste Szenario, jede Einfügung/Aktualisierung in eine Transaktion einzufügen.

Mit Feder erreichen Sie das sehr einfach. Ohne es Sie möglicherweise die Transaktionslogik in Ihrem DAO wieder - d. H. dao.beginTransaction() und dao.commitTransaction() und verwenden Sie diese stattdessen von der Serviceebene.

Wie ich verstehe, schlagen Sie vor, dass die Verwendung der EntityManager direkt in den Serviceklassen wahrscheinlich besser ist als mit einem Wrapper DAO Klasse. Ich stimme einem Grund nicht zu. Wenn Sie die DAO-Klasse (bestenfalls Schnittstelle) in Ihren Serviceklassen verwenden, haben Sie überhaupt keine Abhängigkeit von der JPA-API. Sie müssen keine Query Objekte oder ähnliches konstruieren. Dies könnte sich nicht als großer Vorteil erweisen, aber Sie würden zustimmen, dass es eine Best Practice ist. Und Sie können später zu einfachem JDBC, Klartext, XML oder was auch immer wechseln, indem Sie nur das DAO ändern.

Dies ist, obwohl weit verbreitet als ein Beispiel dafür, warum Sie etwas in einer anderen Schicht abstrahieren sollten, meistens einfach ein Überdesign. Aber manchmal führt die Tatsache, dass alle Ihre Datenbankzugriffsvorgänge an einem Ort stattfinden, dazu, dass Sie Protokollierung, Zugriffsstufenprüfungen usw. hinzufügen können. (Ja, manchmal ist das DAO nicht besonders geeignet, dies zu tun).

Also letztlich, um zu Ihrem Punkt zurückzukehren - es kommt darauf an.

Answer 3

DAO wird für die Design-Perspektive verwendet, während JPA ein "offizieller" Wrapper für Datenzugriffsfunktionen ist. Es gibt keine Möglichkeit, dass JPA versucht, DAO zu killen - es kann DAO einfacher implementieren, vielleicht so einfach, dass DAO so einfach aussieht, dass es ignoriert werden kann. Aber ohne die DAO-Schicht existiert der Designvorteil nicht mehr.

Natürlich kann es für "einfache" Projekte ignoriert werden. Viele Dinge können "ignoriert" werden, wenn das Projekt "einfach" genug ist.