DAO's nas classes de negócio

JavaTeenager Membro desde: 30/03/2006 16:51:25 Mensagens: 196 Offline

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?

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...

SadNess wrote: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(); }

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!

JavaTeenager Membro desde: 30/03/2006 16:51:25 Mensagens: 196 Offline

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

JavaGuru Membro desde: 07/03/2007 15:58:16 Mensagens: 293 Offline

Eu uso a segunda forma citada pelo Marcelo.

Quais sao os problemas q eu posso vir a ter com ela.

Thread.start() Membro desde: 23/03/2005 11:43:10 Mensagens: 45 Offline

Essa segunda também não entendi!!! Alguém poderia esclarecer ?????

marcelo_mococa wrote: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.

YvGa wrote:Eu uso a segunda forma citada pelo Marcelo.

Quais sao os problemas q eu posso vir a ter com ela.

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.

JavaGuru Membro desde: 07/03/2007 15:58:16 Mensagens: 293 Offline

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.

JavaGuru Membro desde: 07/03/2007 15:58:16 Mensagens: 293 Offline

marcelo_mococa wrote:
A control dentre outros papéis (validação, regras de negóciom etc...) será a única que irá conversar com os daos.

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".

JavaGuru Membro desde: 07/03/2007 15:58:16 Mensagens: 293 Offline

jujo wrote: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".

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
}
}

JavaTeenager Membro desde: 30/03/2006 16:51:25 Mensagens: 196 Offline

marcelo_mococa wrote: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.

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?

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