Como o título já diz, este post demonstra algumas implementações para facilitar a cópia de objetos semelhantes.
Para menor acoplamento entre a camada de visualização e o banco de dados, utilizamos DTOs que são (quase) espelhos de Entidades. Ganhamos flexibilidade para criar objetos mais produtivos para o front-end, o que torna(va) o back-end improdutivo.
A cópia de objetos pode ser feita com apenas uma linha de código (6) e mais algumas anotações.
Opniões e colaboração são bem-vindos.
10 Comments
Deixe um comentário
Compartilhe isso:
Parabéns pela idéia Fuster!
Modelar o backend baseado nas telas realmente gera algumas dores de cabeça as vezes.
Já dei fork no projeto. Pode contar com uma força minha!
Boa!
Muito legal Bruster!!!!
Parabéns pela iniciativa
Ola Bruno!
Excelente post e forma de visualizacao.
Realmente DTO tem seus usos, em especial quando queremos expor algo de granularidade diferente das nossas entidades, mas vale lembrar que não devemos criar DTOs automaticamente, sem enxegar uma real necessidade em tal decisão. Fica terrivel dar manutencao a um espelhamento das nossas entidades, alem de aumentar a complexidade do sistema: há uma dependencia fortissima entre as classes (parallel classes anti pattern).
Nesse caso em específico, em que o DTO é identico a entidade, não vejo necessidade em criá-lo. Por que voce achava a entidade antes improdutiva?
abracos
Olá Paulo,
Obrigado pelo seu feedback!
Concordo plenamente com seu comentário! DTOs não devem ser criados automaticamente e sem razão.
A intenção aqui é facilitar um pouco o pattern Transfer Object (as classes idênticas são para fácil entendimento).
Quando utilizamos DTOs com real utilidade o factory method fica muito mais complexo do que o exibido.
Em projetos recentes com flex como front-end venho utilizando bastante DTOs como espelhamentos simples de entidades, o que tem me ajudado muito com problemas de serialização, proxys não inicializados e manter objetos iguais aos do flex (sem propriedades mantidas somente pelo back-end) diminuindo o tráfego do AMF. (ex: muitas entidades tem user como owner, mas o front-end não precisa saber disso em todos objetos).
Acredito que em projetos 100% java este pattern deve ser utilizado em casos raros.
Quando disse improdutivo queria me referir a manter espelhamentos de entidades.
Abraços,
excelente bruno, estou de acordo! pior que voces do flex ainda tem de espelhar muitas das entiades no actionscript… haja paciencia.
Haja paciênia mesmo Paulo. Pelo menos no Flash Builder 4 foi incorporado uma fetaure para gerar as entidades do Java para o AS e vice-versa.
[…] Fonte dto, ejb, patterns […]
Bruno, estava lendo e deixa eu te perguntar o DataTransferObjectManager eu tenho que implementar? ou ja existe em algum lugar??
obrigado
Olá Fabio, você pode pegar no GitHub.
git clone git@github.com:bfuster/dtomanager.git
http://github.com/bfuster/dtomanager