A conclusão q tiramos disso é q o DTO (e uma grande parte dos outros Padrões do catálogo J2EE Core-Patterns) só foi "inventada" para melhoria de performance (para "suprir uma deficiência da" "API do EJB").

Mas, acho q podemos tirar boas lições (e dicas). Garcia, em outro post vc levantou interessantes aspectos: 1 deles é o "do Desenvolvedor UI q chama 1 'User.getRoles().clear()' e depois poderia salvar o User". Sei q já estou começando a ir off-topic, mas não tem jeito:
[off-topic - ***]
para o atributo 'roles' (para não dizer bobo) seria estúpido disponibilizar um método 'setRoles()' => se o q realmente faz sentido é adicionar (ou remover) papeis de um Usuário. Isto é uma falha de Modelagem: não fizemos o 'Hidding of Information'! E quanto ao 'User.getRoles()', a falha é maior ainda, pois acabamos expondo a estrutura Interna (q poderia ser um array (de Role's), um List, um Set, ou até mesmo um (Hash)Map) da Composição de Papeis de um Usuário; quando o correto seria (além de forncecer o métodos adicionar e remover) fornecer um método q retornasse, não a própria Referência do atributo (interno) Roles, mas uma cópia (um tipo de Clone) desta composição. Conseguem me compreender?!

garcia-jj wrote:Derlon, há dois bons artigos que podem acrescentar na discução sobre lazy-load, dtos e afins.
http://community.jboss.org/wiki/HibernateinaLayeredArchitecture
http://community.jboss.org/wiki/RemoteLazyLoading

A conclusão q tiramos disso é q o DTO (e uma grande parte dos outros Padrões do catálogo J2EE Core-Patterns) só foi "inventada" para melhoria de performance (para "suprir uma deficiência da" "API do EJB").

Muito espírito crítico para saber avaliar cada um dos patterns. Muitos são inúteis em alguns casos, mas úteis noutro. O pior que conheci um projeto em EJB 2.1 que usava TODOS os patterns. E sabe que ficou bem elegante? No caso desse projeto era mesmo necessário usar aquilo tudo, mas hoje em dia com EJB3 eu não faria assim.