Pessoal estou com uma dúvida muito grande.
Estou desenvolvendo um sistema Utilizando JSF 2 + EJB 3.1 + CDI.
Estudei os mesmos em artigos e específicações.
Vi que em alguns não aconselham usar EJB na DAO, mas outros já utilizam.
Alguns usam services e outros BO, alguns com interface e outros sem.
Usam os Manage Bean como Modelo (onde acho que é uma união de Controller com Visão), outros usam como Controller.
Então gostaria de uma forma mais centrada de dividir estas camadas…
Onde cada componente se encaixa no MVC.
Obrigado!!!
Já Pensou em utilizar VRaptor neste projeto, pode facilitar
e muito sua vida , pesquise sobre o assunto 
Como assim “usar EJB na DAO”? Você quer dizer chamar um EJB dentro de um DAO ou criar um DAO como EJB? A segunda opção eu já vi, criar um DAO como EJB stateless para ter o Entity Manager injetado, mas com CDI não sei precisar se vale à pena fazer isso. Numa arquitetura convencional uma camada de serviço chama um DAO quando precisar acessar um repositório de dados. Quanto a chamar um EJB dentro de um DAO pode ser que exista um caso ou outro em que faça sentido, mas normalmente quando você pensa nisso é porque está tentando colocar regras de negócio no DAO.
Tente fazer deste modo conforme o diagrama de componentes abaixo. Utilizo o padrão de projeto Facade. Nele vc expoe seus serviços através de interfaces.
Então , qual o padrão para essa arquitetura ??
Eu estou com essa duvida , fiz um projeto apenas EJB+ JSF
No EJB fica so os DAO , Regras Negocios e suas interfaces .
No JSF fica apenas os ManagerBeans com suas xhtml …
??? Essa arquitetura está correto ???
– Caso eu quiser criar um @Sheduler , aonde eu coloco ???
– Caso eu quiser criar um lançador de e-mails … ???
Obrigado …
[quote=MarcolaLipe10]Então , qual o padrão para essa arquitetura ??
Eu estou com essa duvida , fiz um projeto apenas EJB+ JSF
No EJB fica so os DAO , Regras Negocios e suas interfaces .
No JSF fica apenas os ManagerBeans com suas xhtml …
??? Essa arquitetura está correto ???
Obrigado … [/quote]
Arquitetura tem que partir do problema real que voce vai atender. Se por exemplo você nao tem real necessidade de usar EJB, ja nao é correto nem relacioná-lo.
[quote=javaflex]
Arquitetura tem que partir do problema real que voce vai atender. Se por exemplo você nao tem real necessidade de usar EJB, ja nao é correto nem relacioná-lo.[/quote]
Mas a arquitetura acima , ta errada ???
Usar EJB so para persistencia e regras de negocios ???
Pra tudo eu uso EJB .
Tenho um projeto agora pra fazer , é so para controlar tarefas .
A TIM recebe as tarefas e os operadores falam se a tarefa ta em andamento , concluida e uma obs deles.
E vai gerar relatórios de tarefas e outras consultas voltada a tarefa dos operadores !
Tendo disparo por e-mail semanalmente para os operadores sobre a tarefa que ainda nao estar concluida.
Pra isso é necessario EJB ???
Quando é necessario EJB então ???