Utilizar beans de entidades na camada visual?

Olá Fernando,

se esses seus beans são POJOs, não vejo problema algum no fato de eles estarem sendo usados na sua camada de visão (desde que nao estejam gerenciados pela seu PersistenceManager). Se a sua preocupacao é o fato de as anotacoes de mapeamento nos beans estarem tornando sua view acoplada a uma tecnologia/framework de ORM (tipo hibernate ou JPA), entao retire as anotacoes do bean e use mapeamento via XML.

[]`s

wchevreuil:

Olá Fernando,

se esses seus beans são POJOs, não vejo problema algum no fato de eles estarem sendo usados na sua camada de visão (desde que nao estejam gerenciados pela seu PersistenceManager). Se a sua preocupacao é o fato de as anotacoes de mapeamento nos beans estarem tornando sua view acoplada a uma tecnologia/framework de ORM (tipo hibernate ou JPA), entao retire as anotacoes do bean e use mapeamento via XML.

[]`s

Também não vejo nenhum problema, só gostaria que existisse uma forma menos braçal de fazer isso.

Eu não sei se é porque eu venho dos primórdios do inicio do JEE, e sempre trabalhando com aplicações distribuídas eu tenho o costume de sempre usar Transfer Objects. Particularmente eu não gosto de expor para a camada web minhas entidades persistentes.

Normalmente eu crio meus transfer objects especificos para alguma funcionalidade e, conforme a funcionalidade, eu monto os transfer objets buscando os dados das minhas entidades, mesmo que seja em uma aplicação não distribuída.

Há algum tempo eu havia discutido sobre isso nesse tópico: http://guj.com.br/posts/list/15/204519.java#1039241

Eu faço assim também porque você pode optar por expor ou não certas propriedades para a camada web, e até mesmo transformar algum outro dado que você tenha nas entidades. Um exemplo que sempre cito é no caso da sua entidade User possuir um atributo password. Se você usar as entidades na web você poderá sem problemas imprimir a senha na tela. Mesmo que a senha esteja encriptada você vai enxergar alguma coisa. Usando Transfer Object você monta um objeto com tudo que você precisa na tela, e apenas o que você precisa na tela, independente de como estejam esses dados nas entidades.

Concordo, por mais que seja simples utilizar um POJO gerenciado pelo Hibernate (por exemplo) nos backing beans de sua aplicação, na hora de extender as funcionalidades, ou seja, adicionar novos relacionamentos e campos às entidades existentes, dados desnecessários vão começar a ser carregados sem necessidade por toda a sua aplicação.

Uma opção, no caso do Hibernate, seria utilizar sempre classes não mapeadas nas consultas (“SELECT NEW x.y.Z(…)”) contendo apenas os dados necessários para a funcionalidade implementada, de forma que os beans possam escalar e não impactar as páginas antigas.

Não vejo problema em acessar as entidades na camada visual. Algus cuidados:

Caso a entidade exponha uma coleção (composição), utilizo Collections.unmodifiable… para garantir o encapsulamento;
Utilizo value objects para objetos de relacionamento.

Abraços

Desculpe pessoal a demora de alguma resposta, mas é q andei viajando e acessei pouco o guj…

Então…as vezes fico na dúvida, entre a facilidade de utilizar diretamente esses pojos, que são sim utilizados pelo persistence Manager, já que são beans Entity, para preencher os dados da minha View e enviar para a camada de persistência, e o desenvolvimento digamos mais “elaborado”, cuidando principalmente a questão do acoplamento e nesse caso ter que criar as classes “Moto Boys”, que seriam os objetos “Leva-e-Tras” de informações até as camadas inferiores e retornam com a resposta para as views…E se pensarmos bem, essa questão de criar classes que apenas levam informações nós acabamos criando novos acoplamentos, agora de todas as camadas, à esse novo objeto, apenas para não ter dependencia do nosso Bean com a View…complicado…