# DTO - bedeutung in EE5 mit EJB3



## bronks (20. Apr 2007)

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 (20. Apr 2007)

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 (20. Apr 2007)

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 (20. Apr 2007)

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 (21. Apr 2007)

Anonymous hat gesagt.:
			
		

> ... 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 (21. Apr 2007)

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.


----------

