2016-07-07 15 views
2

Ich habe 3 Service-Klassen in meiner Anwendung jeweils für bestimmte Funktionalitäten mit entsprechenden DAO-Schnittstellen & ihre Implementierungsklassen geschrieben. Alle Dienste haben unterschiedliche Pakete.Mit Methoden von einem DAO zu einem anderen

Sagen, ich habe ist

AService.java & ADAO.java ADAO Schnittstelle in AService.java Klasse injiziert. Ebenso habe ich

BService.java & BDAO.java 

CService.java & CDAO.java 

Jetzt habe ich einige Methoden der BDAO & CDao Implementierungsklassen in AService.java

beziehen möchten Was ist der beste Weg, das zu tun sein sollte?

  1. ich spritze BDAO & CDao in AService.java. Wäre das eine gute Übung? Dienste sind in diesem Szenario eng miteinander verknüpft.

  2. Ich schreibe den redundanten Code in entsprechende DAOs.

  3. Ich erstelle eine generische DAO & versuchen, alle gängigen Methoden aus allen einzelnen DAOs & in das zu extrahieren. Dies ist eine umfangreiche Aufgabe. Auch bin ich mir in Zukunft nicht sicher, welche Methode welche DAO in welcher bestimmten Dienstleistung benötigt.

+3

Sie sollten tun 1. Es ist völlig normal, dass ein funktionierender Dienst auf Daten von verschiedenen Entitäten zugreifen muss und somit mehrere DAOs verwendet. –

Antwort

5

Ich würde in diesem Fall mit der ersten Option gehen. Ein Dienst kann ein höheres Abstraktionsniveau haben als die DAOs.

Sicher würde ich nicht mit dem zweiten Ansatz gehen, die dritte Option könnte gültig sein, wenn der gemeinsame Code ein Dienstprogramm-Code ist, würde ich dies nicht tun, wenn der gemeinsame Code von verschiedenen Entitäten/logischen Domäne ist.

+0

Ich stimme der ersten Option nicht zu.Es ist keine gute Idee, DAOs aus anderen Domänen zu injizieren und ihre Business-Logik-Ebene zu umgehen. Oder würden Sie das gleiche in einem Controller tun, - ich denke nicht? – d0x

3

Wenn Sie Verhalten in der DAO-Schicht teilen, sollten Sie es mit Vererbung oder Zusammensetzung (Association) innerhalb der DAO-Schicht tun.

Sie in Scheiben geschnitten Ihre Anwendung von Domains wie „A“, „B“, „C“, so die AService sollte nicht durch die BService passieren Logik, jede Art von B in der B-Domäne implementiert zuzugreifen.

Siehe @oliver-gierke sprechen "Whoops! Where did my architecture go?". Aufgrund dieser einfachen Umgehen schlägt er Pakete wie diese

public  class com.product.a.AService 
/*package*/ class com.product.a.ADao 

public  class com.product.b.BService 
/*package*/ class com.product.b.BDao 

public  class com.product.c.CService 
/*package*/ class com.product.c.CDao 

Damit Sie erzwungen zu organisieren, dass keine andere „Domain“ ist die Daos Ihrer Domain verwenden. Andernfalls können Sie gegen Ihre Architekturregeln verstoßen.

Das Problem bei der Freigabe von DAOs unterschiedlicher Domänen besteht darin, dass Sie businesslogic umgehen können, das in der Serviceschicht der anderen Domänen implementiert ist. Zum Beispiel, mit jeder "löschen" Operation auf B sollte eine E-Mail an einen Kunden gesendet werden. Wenn die AService die BRepository direkt verwendet, gewährt sie Zugriff auf eine B-Instanz zu löschen und die Logik zu umgehen, um eine E-Mail zu senden.

+0

Eine "gemeinsame" DAO-Klasse mit "gemeinsamen Funktionalitäten" zu erstellen, die bei Bedarf von anderen DAOs erweitert werden könnte, hat mir sehr gut getan. Vielen Dank. – DarkPurpleShadow