DAO/DTO - Wohin mit der Geschäftslogik?

[miketech]

Hallo zusammen,

ich habe eine Anwendung, die auf Daten in einer Datenbank mittels JPA zugreift.

Ich habe bisher folgende Struktur:

public class Customer {

// Enthält nun Attribute wie "Name", "Straße" etc., die mittels JPA Annotationen versehen werden
}

public class CustomerManagement {

// Im Grunde mein DAO. Enthält Methoden wie "findBy...", "update", "delete" etc.


}

Zunächst zum CustomerManagement:

1. Sollte update nicht statisch sein? Oder was sind die Vorteile, dass es nicht statisch ist? Ansonsten könnte ich viel bequemer einfach aufrufen: CustomerManagement.update(myCustomer). So muss ich immer erst eine Instanz erzeugen.

2. Sollte ich hier direkt mit dem EntityManager arbeiten? Bsp:

   public void update(Customer customer) {
      entityManager.merge(customer);
   }

Wo ist denn CustomerManagement angesiedelt? In der Datenbankschicht oder Geschäftslogikschicht? Denn wenn Geschäftslogikschicht, dann würde ich noch eine extra Database-Class schreiben:

   public class Database {

       public static void updateCustomer(Customer customer) {
               entityManager.merge(customer);
       }
   }

[code]

Mir stellt sich nun die Frage, wo ich die Geschäftslogik unterbringen soll. Bspw eine Methode: verifyCustomer(Customer customer), die die Daten eines Kunden hinsichtlich Geschäftslogik prüft. Also nicht DB-orientiert, sondern aus der Geschäftslogik heraus soll die Prüfung erfolgen.

Packe ich das nun in die CustomerManagement-Klasse oder in die Customer-Klasse?

[code]
public class Customer {
   public boolean verify() {
   ....
   }
}

public class CustomerManagement {
   public boolean verify(Customer customer) {
   ....
   }
}

Oder nehme ich dafür eine andere Klasse? Bspw:

CustomerManagement wird zu CustomerDAO und CustomerManagement enthält die Geschäftslogik?

Würde mich sehr interessieren, wie man das am besten macht.

Gruß

Mike

 

[fastjack]

Manager benutzen Dao's um Geschäftslogik abzubilden. Die Dao's greifen auf die Daten zu, z.B. CRUD-Methoden.

 

[miketech]

Hallo,

danke für Deine Antwort. D.h. ich habe DAOs in der Datenschicht und Management in der Geschäftslogik. Dann mache ich das so

Gruß

Mike

 

[Gast2]

Der EntityManager kann als DAO angesehen werden...

JPA/EJB3 killed the DAO : Adam Bien's Weblog

 

[miketech]

D.h. ich würde im Management direkt auf den EntityManager zugreifen ohne ein DAO zu verwenden? Wann die Sache mit Transactions, die man beginnt und dann wieder beendet trotzdem sehr technisch.

Und wenn es über CRUD hinausgeht nutze ich noch einen DAO? Oder nutze ich namedQueries im EntityManager?

Gruß

Michael

 

[Gast2]

D.h. ich würde im Management direkt auf den EntityManager zugreifen ohne ein DAO zu verwenden? Wann die Sache mit Transactions, die man beginnt und dann wieder beendet trotzdem sehr technisch.

Und wenn es über CRUD hinausgeht nutze ich noch einen DAO? Oder nutze ich namedQueries im EntityManager?

Gruß

Michael

Ja ich würde die Management Sachen eher als Services ansehen.
Ja klar wenn du komplizierte Datenabgriffe hast kannst du dir immer noch ein DAO basteln oder queries nutzen...

Aber für einfache CRUD Sache würde ich den EntityManager nehmen und den Service als Interface und dann eben eine JPAImplementierung machen.

 

[Sanix]

Wegen dem ewigen instanzieren deiner Manager resp. Serviceklassen:
Falls du einen Application Server verwendest kannst du EJBs verwenden. Bei Standalone Applikationen z.B. Spring und dann mit dependency injection arbeiten.