Das DAO-Pattern bietet eine Abstraktion auf die Persistenzschicht.
Gegeben sei eine n:m Relation zwischen den Datenbanktabellen Kunde und Artikel über eine Übergangstabelle Bestellung:
Kunde n----1 Bestellung 1----m Artikel
Kunde-Artikel sei hier als Beispiel genannt. Das Problem tritt bei jeder Relation im DAO-Pattern auf!
Die Daten werden über DataTransferObjects (DTO) ausgetauscht. Es gibt also KundeDTO und ArtikelDTO. In der KundeDTO gibt es eine Collection der Bestellungen, welche alle ArtikelDTO beinhalten, die der Kunde bestellt hat.
Bsp. Collection<ArtikelDTO> getAllArtikel();
In der ArtikelDTO wiederum gibt es eine Collection aller KundeDTOs, die mit diesen Artikeln verknüpft sind. Da es dann auch in ArtikelDTO eine Methode gibt, wie Collection<KundeDTO> getAllKunden(); entsteht leicht ein "Kreislauf":
Ich komme an eine KundeDTO und hole mir eine ArtikelDTO und daraus wieder eine KundeDTO usw.
Meine Frage ist nun die Erstellung der DTOs. Falls man streng Objektorientiert vorgehen würde, müsste man beim erstellen einer DTO auch alle abhängigen DTOs bilden und der Klasse hinzufügen. Es würde jedoch sofort zu einer Endlosschleife kommen.
Wir haben uns bisher 2 mögliche Auswege gesucht:
1. Es werden in der DTO nicht die abhängigen DTOs gespeichert, sondern nur die IDs
Vorteil: Keine Rekursion
Nachteil: Keine "echte" objektorientierung, da ich, um an eine abhängige DTO zu gelangen, mit der ID eine DAO-Methode aufrufen muss.
2. Unterschiedliche DAO-Methoden zum generieren der DTO:
I. Die DTO enthält keine weiteren DTOs, sondern nur die abhängigen IDs. Um an eine abhängige DTO zu gelangen, muss mit der gespeicherten ID eine DAO-Methode aufgerufen werden.
II. Man erhält eine DTO mit genau EINER Stufe abhängiger DTOs. Z.B. wäre in Kunde eine Collection aus ArtikelDTOs, welche jedoch vom Typ I. wären. In ihnen steckt also anstatt einer DTO eine ID.
Vorteil: In den meisten Fällen dürfte eine STufe ausreichend sein. Zur Not gelangt man über die ID an eine DTO.
Nachteil: 2 unterschiedliche Arten von DTOs. Erhöhter programmieraufwand.
Die mir bekannte Literatur überlässt es dem Progrmmierer dieses Problem zu meistern. Core J2EE Patterns geht überhaupt nicht auf das Problem ein.
Kennt jemand Best-Practices zu diesem Problem oder hat eine bessere Möglichkeit die Abhängigkeiten aufzulösen?
Danke und
Glück Auf
Timo
Gegeben sei eine n:m Relation zwischen den Datenbanktabellen Kunde und Artikel über eine Übergangstabelle Bestellung:
Kunde n----1 Bestellung 1----m Artikel
Kunde-Artikel sei hier als Beispiel genannt. Das Problem tritt bei jeder Relation im DAO-Pattern auf!
Die Daten werden über DataTransferObjects (DTO) ausgetauscht. Es gibt also KundeDTO und ArtikelDTO. In der KundeDTO gibt es eine Collection der Bestellungen, welche alle ArtikelDTO beinhalten, die der Kunde bestellt hat.
Bsp. Collection<ArtikelDTO> getAllArtikel();
In der ArtikelDTO wiederum gibt es eine Collection aller KundeDTOs, die mit diesen Artikeln verknüpft sind. Da es dann auch in ArtikelDTO eine Methode gibt, wie Collection<KundeDTO> getAllKunden(); entsteht leicht ein "Kreislauf":
Ich komme an eine KundeDTO und hole mir eine ArtikelDTO und daraus wieder eine KundeDTO usw.
Meine Frage ist nun die Erstellung der DTOs. Falls man streng Objektorientiert vorgehen würde, müsste man beim erstellen einer DTO auch alle abhängigen DTOs bilden und der Klasse hinzufügen. Es würde jedoch sofort zu einer Endlosschleife kommen.
Wir haben uns bisher 2 mögliche Auswege gesucht:
1. Es werden in der DTO nicht die abhängigen DTOs gespeichert, sondern nur die IDs
Vorteil: Keine Rekursion
Nachteil: Keine "echte" objektorientierung, da ich, um an eine abhängige DTO zu gelangen, mit der ID eine DAO-Methode aufrufen muss.
2. Unterschiedliche DAO-Methoden zum generieren der DTO:
I. Die DTO enthält keine weiteren DTOs, sondern nur die abhängigen IDs. Um an eine abhängige DTO zu gelangen, muss mit der gespeicherten ID eine DAO-Methode aufgerufen werden.
II. Man erhält eine DTO mit genau EINER Stufe abhängiger DTOs. Z.B. wäre in Kunde eine Collection aus ArtikelDTOs, welche jedoch vom Typ I. wären. In ihnen steckt also anstatt einer DTO eine ID.
Vorteil: In den meisten Fällen dürfte eine STufe ausreichend sein. Zur Not gelangt man über die ID an eine DTO.
Nachteil: 2 unterschiedliche Arten von DTOs. Erhöhter programmieraufwand.
Die mir bekannte Literatur überlässt es dem Progrmmierer dieses Problem zu meistern. Core J2EE Patterns geht überhaupt nicht auf das Problem ein.
Kennt jemand Best-Practices zu diesem Problem oder hat eine bessere Möglichkeit die Abhängigkeiten aufzulösen?
Danke und
Glück Auf
Timo