Uma questão que vem me encomodando e gostaria de saber como vocês lidam com ela.
Divido o meu sistema em camadas, onde tenho, no caso de aplicações WEB, minhas páginas .xhtml, os backing beans, façades, camada de serviços, camada de persistência.
Tenho minhas entidades na qual faço as anotações de mapeamento do banco de dados, na camada de persistência.
O que gostaria de saber é se vcs utilizam essas mesmas classes de entidade, esses beans que servem de classes para mapeamento no banco, nos backing beans, que considero ainda como uma camada visual do sistema.
Não estaria aumentando o acoplamento dessa camada? Como resolver isso caso não queira fazer dssa forma…utilizar um wrapper?? e consumir mais processamento, pegando esse wrapper nas camadas posteriores e preenchendo os valores dos beans de entidade referentes?? utilizar um VO???
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.
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[/quote]
Eu concordo com o Fernando, e não vejo nenhum problema em utilizar em seus backing beans estas classes de entidades.
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.
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.
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…