galera, como vc fazem quando têm em um objeto de negócio a necessidade de carregar algo do banco? vc’s chamam seus DAO’s dentro dos métodos de negócio?
Ex: tenho uma classe Setor, que tem um método listarUsuários(), sendo que a lista de usuários deste setor está armazenada no banco
como vcs fariam?
public List<Usuario> listarUsuarios() {
setorDAO.listar();
}esta é uma abordagem correta? se não, que alternativa vcs usam?
seu método de negócio nao faz nada a nao ser recuperar a lista?
entao talvez nem na camada de negócio ele precise estar…
[quote=SadNess]galera, como vc fazem quando têm em um objeto de negócio a necessidade de carregar algo do banco? vc’s chamam seus DAO’s dentro dos métodos de negócio?
Ex: tenho uma classe Setor, que tem um método listarUsuários(), sendo que a lista de usuários deste setor está armazenada no banco
como vcs fariam?
public List<Usuario> listarUsuarios() {
setorDAO.listar();
}
[/quote]
Em algum ponto você vai ter que chamar o DAO numa classe de negócio, não é? 
Acho que o seu problema é “quando”.
A forma que você colocou pode ser interessante, principalmente se você tiver que executar alguma outra regra de negócio antes de obter os dados do banco, como verificar a permissão de um usuário para ver a lista de todos os usuários cadastrados.
essa discussão vai longe…
você tem duas formas de fazer isso.
1ª: exatamente como o RafaelRio disse. Seu objeto de negócio vai precisar conhecer o dao para fazer a consulta.
Parece mais OO.
2ª: a forma mais usada. Você criará uma camada de classes controles e elas serão as responsáveis de fazer este tipo de transação.
Não entendi a 2a. opção.
O seu modelo vai ter que chamar o DAO direta ou indiretamente.
Como o DAO por si só já é uma abstração para a camada de persistencia, não vejo problema algum em o seu modelo chamar o DAO. Veja que como eu acabei de falar o DAO deve ser uma interface independente de qualquer coisa relacionada ao mecanismo de persistencia, ou seja, vc tem userDAO e MySQLUserDAO, HibernateUserDAO, FileUserDAO, LDAPUserDAO, OracleUserDAO, e por aí vai… Pode ter também um JdbcUserDAO, que ficaria abaixo de MySQLUserDAO e OracleUserDAO.
Criar mais uma abstração em cima do DAO para acessar a camada de persistencia me parece um grande overkill, mas posso estar enganado…
O que seria bastante equisito é acessar o DAO diretamente da sua action!
valeu galera
eu tava com um pé atrás de colocar os DAOs nos objetos de negócio, mas agora estou percebendo que é uma abordagem correta
vlw pela ajuda
Eu uso a segunda forma citada pelo Marcelo.
Quais sao os problemas q eu posso vir a ter com ela.
Essa segunda também não entendi!!! Alguém poderia esclarecer ???
[quote=YvGa]Eu uso a segunda forma citada pelo Marcelo.
Quais sao os problemas q eu posso vir a ter com ela.[/quote]
Antes de saber se é bom, ruim, legal, recomendável ou não-recomendável, a gente precisa entender o que é a opção 2.
Desculpa pela péssima explicação. Deixa eu tentar explicar melhor a idéia…
A grande maioria dos sistemas que eu conheço trabalha da seguinte forma:
Um objeto que recebe a requisição (action, servlet, etc…).
Esse objeto apenas transforma os dados em um objeto de negócio (Bean) e deixa a tarefa de executar as regras para outra classe, a control. A action apenas conversa com a control.
A control dentre outros papéis (validação, regras de negóciom etc…) será a única que irá conversar com os daos.
Essa é a camada a mais que eu citei… espero ter ficado mais claro agora.
Veja que eu disse que é a maneira mais usada, mas não é tão OO.
Nao sei se eh o mesmo caso q o Marcelo colocou, mas eu faco da seguinte maneira:
A partir da UI o usuario pressiona o botao salvar, q envia a mensagem para um controller (controle.save()). Esse controle tem com um de seus atributos um objeto do dominio, Cliente por exemplo.
É dentro desse metodo save() q ele instancia a classe DAO e passa o objeto do dominio como parametro para ser persistido. O meu objeto Cliente nao conhece nada a respeito de persistencia em tempo algum.
Nesse ponto a minha eh diferente, todas as regras de negocio continuam na classe de dominio, os controles sao responsaveis apenas por direcionar as mensagens recebidas da UI e fazer a ligacao com a camada de persistencia.
A base q eu usei foi a classe q o Craig Larman chama de Registro no “Utilizando UML e Padroes”.
Eu acho qeu a opção 2, ele quiz dizer algo como um Command (ao invés de Controller).
Utilizando-se de Command, você não precisa conhecer o DAO, mas sim, este Command o conhecerá, abstraindo assim o acesso ao DAO, mesmo que ele use mais de um DAO para fazer tal “transação”.
[quote=jujo]Eu acho qeu a opção 2, ele quiz dizer algo como um Command (ao invés de Controller).
Utilizando-se de Command, você não precisa conhecer o DAO, mas sim, este Command o conhecerá, abstraindo assim o acesso ao DAO, mesmo que ele use mais de um DAO para fazer tal “transação”.
[/quote]
Na verdade nao. Eu utilizo os Commands tbm, mas apenas para enviar os valores as classes de dominio, desacoplando da UI.
Os meus controllers sao mais ou menos assim:
public class Controller{
private IModel cliente;
private ISaver saver; //strategy para chamadas das classes DAO
public void salvar(){
this.saver.salvar(this.cliente); //o objeto saver instancia o DAO
}
//demais metodos relacionados a persistencia
public void setValor(ICommand c)
{
//aqui ele recebe da UI um command, passa pra ele o IModel
//nesse caso o this.cliente, o command q e o responsavel por
//“setar” o valor do atributo
}
}
[quote=marcelo_mococa]Desculpa pela péssima explicação. Deixa eu tentar explicar melhor a idéia…
A grande maioria dos sistemas que eu conheço trabalha da seguinte forma:
Um objeto que recebe a requisição (action, servlet, etc…).
Esse objeto apenas transforma os dados em um objeto de negócio (Bean) e deixa a tarefa de executar as regras para outra classe, a control. A action apenas conversa com a control.
A control dentre outros papéis (validação, regras de negóciom etc…) será a única que irá conversar com os daos.
Essa é a camada a mais que eu citei… espero ter ficado mais claro agora.
Veja que eu disse que é a maneira mais usada, mas não é tão OO. [/quote]
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?
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
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…
[quote=SadNess]
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?[/quote]
exatamente…
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?