Pessoal eu ouvi comentar que no EJB 3 o padrão DAO(persistencia) é depreciado, ou seja
para gravar um objedo
eu não preciso ter
[code]
dao.gravar(objeto o){
}[/code]
pois o próprio save do JPA ja encapsula a lógia de persistencia.
finalizando eu não preciso ter uma classe DAO , no proprio bean eu uso o save e beleza.
está correto?
Vc pode ter uma camada de acesso a dados que são Session Beans Stateless, injetando o Entity Manager e parametrizando qual entidade a classe gerencia do modelo.
Então mais o Bean Stateless faz parte da regra de negócio certo?
a minha pergunta é
se eu ter o metodo gravar dentro do bean, ex:
public void gravar(Object o) {
em.save(o);
}
está correto?: a logica de persistencia está encpsulada?
pois eu fazia assim antes, dentro do bean
public void gravar (Object o){
dao.gravar(o); // dentro do dao eu tinha o entityManager
}
Então, há arquiteturas e arquiteturas…simplificando, seus DAOs são Enterprise Java Beans, com isso, eles ganham todo o poder da tecnologia, é isso.
E sim, a persistência fica encapsulada.
Aconselho a leitura desse post do Ricardo Ferreira: http://architecture-journal.blogspot.com/2007/07/enterprise-java-beans-30-anti-patterns.html
Olá Rafael, sei que o post já faz um tempo, mas também tenho duvidas com relação a DAO em EJB3. Gostaria de ver a referência que você colocou, porém o link esta quebrado. Você teria outro link para essa referência? Lembro-me de te-la visitado antes e achei bem interessante, porem não consegui mais acessar o link.
Acho que hoje eu mesmo posso responder…
É como o nosso amigo disse, um EJB pode ser um DAO, mais não necessariamente…
Temos o design patterns repository como alternativa, e indo mais alem, podemos usar DDD…
Como o felipeguerra disse
=)
[quote=erickfm8]Acho que hoje eu mesmo posso responder…
É como o nosso amigo disse, um EJB pode ser um DAO, mais não necessariamente…
Temos o design patterns repository como alternativa, e indo mais alem, podemos usar DDD…
Como o felipeguerra disse
=)[/quote]
Ok erickfm8, obrigado pela resposta.
Então, segue a dúvida. Digamos que eu considere seguir na linha do DDD. Meus repositórios seria classes EJBs?
Se outras camadas, como alguma camada de serviço anterior aos DAOs, já sejam componentes EJB, vejo poucos motivos para você querer que os DAOs também não sejam EJBs.
[quote=rodrigo.uchoa]Se outras camadas, como alguma camada de serviço anterior aos DAOs, já sejam componentes EJB, vejo poucos motivos para você querer que os DAOs também não sejam EJBs.
[/quote]
Obrigado pela resposta rodrigo.
Rodrigo, a questão é:
Claro. Até sem EJB é possível evita-los. Tem sido comum em sistemas com poucas regras de negócio usar uma camada só para negócio e persistência. Até porque, para quem usa JPA, o EntityManager já é uma abstração do acesso ao banco (um DAO genérico). No “service” mesmo faz as duas coisas, sem DAO.
Cara, eu sou um pouco cético com relação ao uso de DDD. A filosofia é muito bonita, mas na prática a aplicação é bem restrita. No meu entender um Repository quase sempre vai ser a mesma coisa de um DAO. Então nesse aspecto você não precisaria dos dois. Mas se formos seguir a filosofia ao pé da letra, os seus Repositórios precisariam utilizar um DAO para acessar o banco em algumas circunstancias.
No meu entendimento que Repository/DAO são a mesma coisa, sim.
Claro. Até sem EJB é possível evita-los. Tem sido comum em sistemas com poucas regras de negócio usar uma camada só para negócio e persistência. Até porque, para quem usa JPA, o EntityManager já é uma abstração do acesso ao banco (um DAO genérico). No “service” mesmo faz as duas coisas, sem DAO.
Cara, eu sou um pouco cético com relação ao uso de DDD. A filosofia é muito bonita, mas na prática a aplicação é bem restrita. No meu entender um Repository quase sempre vai ser a mesma coisa de um DAO. Então nesse aspecto você não precisaria dos dois. Mas se formos seguir a filosofia ao pé da letra, os seus Repositórios precisariam utilizar um DAO para acessar o banco em algumas circunstancias.
No meu entendimento que Repository/DAO são a mesma coisa, sim.
[/quote]
Rodrigo, mais uma vez obrigado pela resposta.
Rodrigo, você tocou no ponto exato.
1)[quote]Tem sido comum em sistemas com poucas regras de negócio.[/quote]Acontece que nos sistemas em que normalmente trabalhamos aqui na empresa, raramente temos este cenário simples de poucas regras de negócio. E não são raras as vezes onde o mecanismo de persistência não se resume a JPA.
2)[quote]Usar uma camada só para negócio e persistência.[/quote]Entrelaçar suas “classes de negócio(domínio)” com “mecanismo tecnológicos de recuperação de dados(infra)” não afetaria questões como acoplamento, coesão, responsabilidade…em fim, isso não podederia comprometer a qualidade interna do seu sistema? Entendo que em um sistema pequeno, onde a preocupação com evolução não é importante acho que realmente essa preocupação minha é desnecessária, mas em um sistema que precisa evoluir com o tempo, acho que separar esses dois interesses traz ganhos futuros. O que você, e quem mais quiser opinar, acham? Me desculpem estender esta discussão, mas acho muito importante o debate.
Se sua necessidade realmente pede, então use mesmo o DAO 
Lembrando que quando falo negócio, eu quis dizer as classes de serviço e não entidades (que normalmente considero sendo o domínio). Isto posto, lembre-se que toda decisão tomada é uma troca: tem pontos negativos e positivos. Você condensar negócio/persistência em uma camada só tem sim seus pontos negativos, mas como eu disse, se você tem pouca regra de negócio, você acaba ganhando em simplicidade/praticidade do design. O que acabaria compensando, em muito, você ter camadas menos coesas e com mais de uma responsabilidade.
Uma observação
[quote]rodrigo.uchoa
Claro. Até sem EJB é possível evita-los. Tem sido comum em sistemas com poucas regras de negócio usar uma camada só para negócio e persistência. Até porque, para quem usa JPA, o EntityManager já é uma abstração do acesso ao banco (um DAO genérico). No “service” mesmo faz as duas coisas, sem DAO. [/quote]
Não considero o JPA uma abstração de DAO tão genérico assim.
Imagine o cenário que você precisa migrar o banco de dados relacional para um banco de dados orientado a objetos, a API de acesso ao dados não é o JPA, é uma API totalmente diferente, desta forma, a ausência de um DAO implica em uma alteração na regra de negocio que já está validada , abstrair essas informações em um DAO por exemplo nos resguardar desse tipo de problema.
[quote]Não considero o JPA uma abstração de DAO tão genérico assim.
Imagine o cenário que você precisa migrar o banco de dados relacional para um banco de dados orientado a objetos, a API de acesso ao dados não é o JPA, é uma API totalmente diferente, desta forma, a ausência de um DAO implica em uma alteração na regra de negocio que já está validada , abstrair essas informações em um DAO por exemplo nos resguardar desse tipo de problema.[/quote]
Concordo com você que nesse caso seria melhor isolar a persistência em DAOs. Entretanto, isso é algo que eu só pensaria se REALMENTE fosse uma necessidade. Eu pelo menos nunca vi acontecer na vida, é bem incomum. Prefiro sempre priorizar a simplicidade do design. Na dúvida, eu nunca faço a mais, sempre a menos