Vc não deveria colocar detalhes do modelo na apresentação, minha opinião. Porem tenho visto alguns casos onde são utilizados JSF, Seam, EJB3 e o pessoal “anexou” entities nos artefatos ref. a apresentação. Não achei que ficou muito ruim pois o entity éra um pojo simples e não necessitava de enhuma transformação para ser utilizado na view logo figou bem simplificado e facilitado.
O risco que percebo neste caso é que no inicio as coisas podem ficar até interessante mas depois pode vir outra pessoa ou vc mesmo e começar a colocar/gerar operações/métodos nestes entities tipicas de view e bagunçar tudo.
sim, então, a minha preocupação inicial era com o fato de passar detalhes do modelo para a camada de apresentação, porém, eu teria que “duplicar” as classes entity beans como pojos (1:1) pq teóricamente são os mesmos atributos, e estamos partindo do princípio que estas classes não teriam métodos.
Estamos utilizando JSF e estamos pensando em mapear os eventos de tela como métodos de uma camada facade, neste caso, acho que não correremos o risco de incluir métodos/eventos de tela no entity.
legal o meu pensamento não está tão fora da realidade
A palavra Entity Beans me deixou um pouco confuso sobre o problema. De qualquer forma, vamos explorar ambos os cenários:
EJB3
No EJB3 não existem mais Entity Beans. A JPA persiste POJOs. Neste caso, não existe nenhum problema em trafegar os objetos até a camada de apresentação. Existem alguns colegas que não gostam desse acoplamento e usam algumas abordagens como (1) duplicar o objeto para desacoplar ou (2) utilizam uma interface e (3) Usam um Memmento.
EJB2
No caso do EJB2, quando você retorna um Entity Bean para o Web Container, na verdade é retornado um Stub, pois geralmente (eu diria quase sempre) o container EJB e Web rodam em JVMs diferentes. Quando você chama getXXX() para retornar alguma coisa nesse stub, na verdade é feito uma chamada remota para obter o dado no objeto real, que está no container EJB. Nesse caso, o uso de DTOs se faz necessário.
Se você estiver na segunda opção (EJB2), fuja disso assim que puder…
Opa.
Acho que a pergunta pode parecer bastante idiota, mas se eu estivesse usando MVC, não seria errado “pular” o controller para enviar direto ao view?
Você não vai pular o controller. Este que vai conversar com o componente model e após isso vai devolver o resultado pro componente View. E num MVC “de verdade”, a view observaria o model, o que na web ainda é um pouco complicado de se fazer, apesar de algumas tentativas com commet (i.e. reverse ajax)
Ah, e é bom lembrar que MVC e camadas são coisas diferentes…