Wie vermeidet man wiederholte DAO-Methoden in Service-Klassen? @Transactional Annotated DAO und Service-Klassen - ist es akzeptabel Übung?

8

Ich weiß, dass es am besten ist, sowohl Service- als auch Dao-Layer zu verwenden und @Transactional-Annotationen auf der Service-Ebene hinzuzufügen. Aber in meinem Fall bedeutet es, dass die meisten meiner Serviceklassen nur dazu dienen, DAO-Methoden zu wiederholen ... Es ist ziemlich irritierend.

z.

%Vor%

Wie dumm ist das?

In den meisten Fällen brauche ich wirklich keine ausgefeilten Service-Methoden, da es sich in der Regel um eine Sache handelt. eine Kategoriebeschreibung und eine Liste von Entitäten, die der Kategorie entsprechen. Deshalb suche ich nach einer vereinfachten Lösung. Etwas so geniales wie Generika zu verwenden, um zu vermeiden, DAOs zu wiederholen: D Ссылка

Ich habe nach der Antwort gesucht. Unter anderem habe ich gelesen Wo gehört die @Transactional Annotation? aber immer noch nicht meine Antwort gefunden.

Ich frage mich also, ob das Kommentieren von DAO-Methoden mit @Transactional wirklich eine so schlechte Idee ist. Inspiriert von Ссылка dachte ich mir eine Lösung aus.

WAS WÄRE:

  • Ich habe nur eine Serviceklasse (die wirklich benötigt wird) und notiere ihre Methoden mit @Transactional
  • für alle anderen (einfachen) Fälle: Ich annotate DAO-Methoden mit @Transactional (propagation = Propagation.MANDATORY) und meine Controller-Methoden mit @Transactional (propagation = Propagation.REQUIRES_NEW)

** UPDATE 1 **

Es würde ungefähr so ​​aussehen:

%Vor%

In jedem Fall verwendet DAO eine Sitzung, die "über" verwaltet wird.

Ist das eine sehr schlechte Idee? Gibt es einen besseren Weg, um das zu erreichen, was ich brauche?

    
Patrycja K 22.04.2013, 12:28
quelle

1 Antwort

2

Ich würde nicht sagen, dass es eine schlechte Idee ist, da es von der Situation abhängt, die Sie gewählt haben, um die Anwendung zu entwerfen.

Wenn Sie glauben, dass Sie keine Serviceklassen benötigen (dh Klassen mit APIs, die mehr als reine DAO-APIs bieten), ist es besser, Serviceklassen zu vermeiden und nur die DAO-Implementierungen zu verwenden, die direkt in den Controller verdrahtet sind.

Aber wenn Sie zusätzliche Logik benötigen und diese als API offen legen möchten, können Sie die Serviceklasse schreiben, die diese benutzerdefinierte Logik und auch die Wrapper-Funktionen für diese DAO-Methoden implementiert (wie Sie oben angegeben haben). . Dadurch wird der Code sauberer, da Sie nur die Serviceklassen in den Controller übertragen müssen und gleichzeitig die DAO-Aufrufe mithilfe der Wrapper-APIs in den Serviceklassen durchführen können.

Wenn Sie Serviceklassen nur für benutzerdefinierte APIs beibehalten und keine Wrapper-APIs von DAO verwenden, müssen Sie auch DAO in Ihre Controller-Klasse integrieren, wenn Sie Datenzugriffsaufrufe durchführen müssen. In diesem Fall werden Sie also DAO's in Service-Klassen und Controller-Klassen verbinden.

UPDATE 1

Hier sind meine Controller- und Service-Klassen aus einem der Beispielprojekte

Controller

%Vor%

Serviceklasse

%Vor%

Wie Sie sehen, ist der einzige Dienst in der Controller-Klasse verdrahtet, und Daos sind mit der Serviceklasse verdrahtet. Dies ist, was ich im gemischten Modus meinte. Entschuldigung, wenn ich dich verwirrt habe.

    
Dhanush Gopinath 22.04.2013 12:58
quelle