DTO - bedeutung in EE5 mit EJB3

[bronks]

Hi!

Bei J2EE hat man den meißten Aufwand damit betrieben TOs durch die Schichten zu würgen und die Architektur entsprechend zu gestalten.

Es finden sich viele Dokus zu EJB3. Dummerweise findet man, wie immer, total widersprüchliche Aussagen.

Wird in Verbindung mit EE5 und EJB3 das DTO-Pattern unverändert weiterverwendet, wie in J2EE oder verzichtet man darauf, da EE5 dafür sorgt, daß die Kommunikation nicht ausartet?

Danke

Bronks

 

[Ullenboom]

DTOs bleiben wichtig, auch bei JPA/Java EE 5 Anwendungen. Der Grund ist einfach: Man möchte nicht unbedingt dem Client eine serialisierte Version der Entity-Bean schicken, die mit *allen* Eigenschaften und Annotationen versehen ist.

 

[bronks]

Danke! Genaus so ist es! Ich bin etwas ins Zweifeln geraten, da ich bei vielen EE5-Tuts gesehen habe, daß im Client mit den Entity-Beans hantiert wird.

 

[Guest]

Auch bei Webservices sind "schlanke" DTOs besser als komplette Datenstrukturen durch die Leitung zu jagen.
Entity-Beans sind allein schon deswegen dazu nicht geeignet, da sie i.d.R. jede Menge von Collections etc.
enthalten, um die Relationships abzubilden. Bei der Serialisierung kann dann leicht passieren, dass man die
halbe Datenbank durch die Leitung schleift.

 

[bronks]

... Bei der Serialisierung kann dann leicht passieren, dass man die
halbe Datenbank durch die Leitung schleift.

Das ist genau der Punkt, bei dem ich gemeint habe, daß EE5 in diese Richtung optimiert ist.

 

[Ullenboom]

Besonders Abhängigkeiten sind da eher lästig. 1:n-Assoziationen sind im Allgemeinen lazy. Serverseitig ist das OK, dann da kommen die DB-Anfragen erst dann, wenn das gebraucht wird. Aber wird das alles zum Client geschickt, ist noch nicht mal sicher, ob tatsächlich die assoziierte Sammlung nötig ist, aber alles wird übermittelt. Zudem ist das bei Hibernate lästig, die lazy Collection (etwa PersistentSet), zu einer üblichen java.util.-Collection zu machen, damit der Client keine Abhängigkeiten zu den Hibernate-Klassen benötigt.