im Vergleich zu not-detatched/ connected Entities? bei zusätzliche DTO-Klassen als Alternative besteht diese Gefahr ja auch nicht gerade 
detached mag die zusätzlichen Klassen sparen und manche Stellen elegant lösen, ist aber das komplexe Modell,
weder in der Präsentation, noch dahinter, Serviceschicht oder was immer kommt, kann man nun sicher sein, was vorliegt, detached oder doch nicht?
wenn die Präsentationsschicht komplett ohne Session geplant ist, dann dort etwas ruhiger
gibt es Massendaten, tausend Mal Id und 5 Attribute benötigt von komplexen Entities mit 20 Attributen und Querverknüpfungen?
in DTO beliebig übertragbar, in Queries mit Teil-Konstruktoren nutzbar
DTO bieten die Möglichkeitl, mehr Methoden + Daten vereinfacht vorzuhalten, die sonst nur über verküpfte Entities in Kette abzufragen wären,
die man in den richtigen Entitäten lieber nicht haben willl
z.B. in einem selbstprogrammieren Forum zu einer Suchanfrage eine Liste von Threads/ Postings mit Zusatzinfos was darin genau gefunden/ markierter Text,
oder für Übersichten nur mit Threads die Anzahl Antworten (redundant zur Antworten-Liste) + Zusatzanzeigen wie ‚Du hast selber darin gepostet‘,
andersrum kann in den DTO auf DB-Ballast wie Annotations verzichtet werden, wobei ich persönlich davon eh abrate
ebenso manche Attribute, DB-Versionsnummer, im Forum-Beispiel Infos zum User-Passwort (Hash)
DTO-Klassen + Copy-Konstrukturen sind redundant, aber nicht zu verachten kann dieser Code abgetrennt in bestimmten packages liegen,
teils eigenen Projekten wie Common, wenn in alle Welt übertragen
dieser Code stört nicht in den wichtigen Klassen, ist meist einfach zu erweitern falls neue Attribute dazukommen usw.
um paar Code-Zeilen an wichtigen Stellen zu sparen lädt man MB-große Libraries, in diese Richtung geht das hier auch:
fast egal wieviel sekundärer Standardcode irgendwo dazu kommt, falls es den wichtigen Klassen für besseres Programmiermodell hilft, dann akzeptabel
mit detachted Entities kann man auch alles schaffen, hat aber tausend Problemen, die als Profi natürlich beherrschbar sind,
die wichtige Grenze zwischen DB-nahen kontrollieren Entities und sonstiger Programmverarbeitung ist unsichtbar (!), das könnte man als kapitalen Modell-Mangel sehen
DTO ist eine klare Trennung zwischen DB und anderem, mit Aufwand (aber auch Möglichkeiten, Erweiterungen), dafür aber sorglose strukturell garantiere Fehlerfreiheit (in bestimmter Hinsicht…, in anderer wie Vergessen von Attributen bei Copy-Konstruktor dagegen…)
(das war nun ziemlich einseitig, Gegenseite kann wer anders übernehmen )
