22 out 2009

Transfer object pattern & annotations

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.

http://github.com/bfuster/dtomanager
Mirror DSL

Core J2EE Patterns, Transfer Object
Factory method pattern

Comments

  • David Paniz
    outubro 22, 2009 Responder

    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!

  • Rodrigo Facholi
    outubro 22, 2009 Responder

    Boa!

  • Henrique F. Marino
    outubro 23, 2009 Responder

    Muito legal Bruster!!!!
    Parabéns pela iniciativa

  • Paulo Silveira
    outubro 24, 2009 Responder

    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

  • Bruno Fuster
    outubro 24, 2009 Responder

    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,

  • Paulo Silveira
    outubro 24, 2009 Responder

    excelente bruno, estou de acordo! pior que voces do flex ainda tem de espelhar muitas das entiades no actionscript… haja paciencia.

  • Rafael Martinelli
    outubro 26, 2009 Responder

    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.

  • Fabio
    julho 23, 2010 Responder

    Bruno, estava lendo e deixa eu te perguntar o DataTransferObjectManager eu tenho que implementar? ou ja existe em algum lugar??

    obrigado

  • Bruno Fuster
    julho 23, 2010 Responder

    Olá Fabio, você pode pegar no GitHub.

    git clone git@github.com:bfuster/dtomanager.git

    http://github.com/bfuster/dtomanager

Leave a Comment