DAO's nas classes de negócio

Acho que quando ele disse control, ele quiz dizer modelo de negócios.

Acredito que o certo é:

Requisição Web -> Action -> Modelo de Negócios -> DAO -> Implementação de DAO

Não vejo como ser diferente disso.

O que algumas pessoas fazem, o que não é recomendável, é:

Requisição Web -> Action -> DAO -> Implementação de DAO

E tem aqueles que vão fazer assim tb:

Requisição Web -> Action -> Banco de Dados

JavaChild Membro desde: 23/08/2006 11:07:21 Mensagens: 130 Offline

Com o JPA, qual seria a desvantagem de fazer o CRUD por exemplo numa camada de negocio?

ffranceschi wrote:Com o JPA, qual seria a desvantagem de fazer o CRUD por exemplo numa camada de negocio?

Boa pergunta.

Respondo com outra.

E se amanhã vc precisar fazer uma query mais complexa, que exiga por exemplo pegar a connection e fazer um SQL mais sinistro? Vc vai fazer essa query dentro do seu modelo de negócios?

Já tive essa mesma dúvida no passado. A session do Hibernate/JPA pode ser considerada uma espécie de DAO, mas na verdade ela não é isso.

Melhor separar claramente a abstração do seu mecanismo de persistencia num DAO e não atrelar a sua opção de JPA, Hibernate, MentaBean ao seu modelo de negócios...

SadNess wrote:

o que eu não entendi aqui é:
o objeto de negócios não possui nenhuma regra de negócios então?
toda a regra de negócio está em uma classe de controle?

exatamente...

JavaChild Membro desde: 23/08/2006 11:07:21 Mensagens: 130 Offline

saoj wrote:
E se amanhã vc precisar fazer uma query mais complexa, que exiga por exemplo pegar a connection e fazer um SQL mais sinistro? Vc vai fazer essa query dentro do seu modelo de negócios?

Melhor separar claramente a abstração do seu mecanismo de persistencia num DAO e não atrelar a sua opção de JPA, Hibernate, MentaBean ao seu modelo de negócios...

Concordo que para query complexas ficaria bem confuso(e dificil de fazer) isso no seu modelo de dominio (parece que com Ibatis vc ate consegue fazer umas querys mais complexas, mas nao conheco pra falar, talvez alguem que conheca poderia opiniar), mas se for pensar num modelo bem simples onde apenas há um CRUD, valeria a pena ter no sua classe (Cliente por exemplo) os metodos insert, delete, update, select apenas delegando para uma classe DAO?
Modelos complexo acho que é interessante separar as camadas, mas modelos simples creio que nao, o que acha?

Objetos de negócio que sabem o que significam DAOs quebram o princípio da inversão de dependências. DAO é algo concreto, ligado com a infra estrutura e não deve ser relacionado diretametne por um objetod e negócio.

Neste caso, use o padrão Repository. Note que um Repository pdoe ser apenas uma interface implementada por um DAO mas o importante é que um Repository é um conceito de negócios, um DAO não, por isso não liguem seus objetos de negócio aos DAOs.

DAO é uma coisa abstrata, não concreta. É uma interface que não é atrelada a nenhuma infra-estrutura.

Se eu tenho uma interface userDAO, ela pode ter qualquer tipo de implementação, inclusive TestUserDAO, DummyUserDAO, etc.

Se vc fala para o modelo de negócios não acessar o DAO, então ele acessaria o que? Acessar esse repositório, só estaríamos passando o problema do DAO para o repositório, não?

Ex do seu modelo de negócios:

Se o meu modelo de negócios não acessar o DAO acima ele vai acessar o que? Me interessei pelo que vc falou, mas estou com medo estarmos criando uma camada extra a troco de nada, o que seria um anti-pattern...

Um DAO não poderia ser considerado como um repositório de objetos e operações relacionadas a camada de persistencia? Vale a pena abstrair o DAO em mais uma camada chamada repositório?

De repente vale, não sei... O repositório é que se encarregaria de saber qual DAO usar e o Modelo usaria sempre o mesmo repositório... Não sei, ainda acho que uma interface userDAO tem exatamente essa função, ou seja, o modelo de negócios utiliza uma interface e essa interface que vai se virar para saber que implementação ela vai usar...

Debugger Membro desde: 16/09/2006 11:16:01 Mensagens: 69 Offline

Eu acho q o saoj esta correto, imagina o tanto de classe que precisaria ser
criada pra fazer um simples crud..
poxa, jah temos uma interface UserDao, que abstrai o dao, entao criar mais
uma camada acho desnecessario minha opinião é

web -> action > model -> interface dao -> dao concreto -> banco

oque entendi estao querendo abstrair do model para o interface

web -> action > model -> repositorio > interface dao -> dao concreto -> banco

não vi finalidade apenas...

É uma questão de conceito. Se você tem uma interface dao para cada entidade do sistema (UserDao, ClienteDao, NotaFiscaDao) que não deixa pistas que tem um banco de dados embaixo dela e seus daos só fazem insert, update, delete e buscas (buscas previstas pela regra de negócio), vc na prática está trabalhando com repositórios. O que não é legal é passar a sessão do hibernate ou um dao genérico pro objeto de negócio.

Se você vai dar o nome de UserDao, UserStore ou UserRepository pra interface é só um detalhe.

[]'s

Rodrigo Auler

Debugger Membro desde: 16/09/2006 11:16:01 Mensagens: 69 Offline

Exatamente, é ai que entra IoC (Inversion Of Control) para
injetar dentro do modelo o Dao.

ai sim o IoC funciona como um repositorio +- , porque ele que vai dizer qual
implementação de DAO que vc vai utilizar.

Antes que essa thread fique parecendo uma cacofonia em hospicio:

DAO: implementacao concreta do Repository. Nao deve ser usada por classes do dominio.

Repository: definicao da interace com o repositorio de dados (nao necessariamente uma interface, mas no maximo uma classe abstrata). Pode ser usada por classes do dominio, preferencialmente via injecao de dependencias.

Espero que fique mais facil se comunicar

Debugger Membro desde: 16/09/2006 11:16:01 Mensagens: 69 Offline

cv , agora não entendi mais nada, não consigo enchergar
isso na prática, e a verdadeira finalidade.

GUJ Ranger Membro desde: 27/04/2005 18:52:49 Mensagens: 822 Offline

A distribuição de classes seria mais ou menos isso ?

Sim, so que sem essa putaria de ClientBO, ClientVO e ClientBOImpl.

Leia: http://en.wikipedia.org/wiki/Test-driven_development

saoj wrote:DAO é uma coisa abstrata, não concreta. É uma interface que não é atrelada a nenhuma infra-estrutura.

Não, Sérgio. DAO é algo que mapeia uma coisa apra outra, é um DataMapper. Ao pedir seus objetos para um DataMapper você está automaticamente sabendo que seus objetos na verdade estão em outro lugar.

Seja este lugar Oracle, hibernate, MySQL, XML ou Lucene isso é algo que não tem a ver com sua Camada de negócios. A Camada de Negócios modela negócios, ponto final, e existem poucos ramos onde o cliente lida com coisas como persistência.

saoj wrote:
Se vc fala para o modelo de negócios não acessar o DAO, então ele acessaria o que? Acessar esse repositório, só estaríamos passando o problema do DAO para o repositório, não?

Não, Repositório é um conceito de negócios, é basicamente uma lsita com métodos mais interessantes.

saoj wrote:
Se o meu modelo de negócios não acessar o DAO acima ele vai acessar o que? Me interessei pelo que vc falou, mas estou com medo estarmos criando uma camada extra a troco de nada, o que seria um anti-pattern...

Você não está criando Camada alguma, você já criou (e está no título deste tópico): a camada de negócios. Repositório==negócios, DAO=persistência.

DAO abstrai apenas a lógica de persistência, não o fato de haver uma persistência, que deve ser abstraído da classe de negócios.

cv wrote:Sim, so que sem essa putaria de ClientBO, ClientVO e ClientBOImpl.

Leia: http://en.wikipedia.org/wiki/Test-driven_development

E

http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs

Não use VO/BO, use objetos

Notícias, artigos e o maior fórum brasileiro sobre Java