Estou desenvolvendo um sistema e usando daos e surgiram algumas dúvidas.
1- Tenho uma tabela que tem uma Fk na classe de transporte (Beans) ela vira um outro objeto?
Ex.: Tenho uma tabela CLIENTE e nela tenho id_endereco, eu teria que montar uma classe Cliente com um objeto Endereco dentro dela?
2- Na classe ClienteDAO vou ter um metodo que tem um select, neste select vai ter uma outra chamada da EnderecoDAO para pegar o endereco relacionado com o cliente? Então este select da ClienteDAO retornar um objeto Cliente com os seus dados e um objeto Endereco dentro dele?
3- Estou colocando toda a regra de negocio no banco, com procedures, DAO é a melhor opção?
Estou desenvolvendo um sistema e usando daos e surgiram algumas dúvidas.
1- Tenho uma tabela que tem uma Fk na classe de transporte (Beans) ela vira um outro objeto?
Ex.: Tenho uma tabela CLIENTE e nela tenho id_endereco, eu teria que montar uma classe Cliente com um objeto Endereco dentro dela?
2- Na classe ClienteDAO vou ter um metodo que tem um select, neste select vai ter uma outra chamada da EnderecoDAO para pegar o endereco relacionado com o cliente? Então este select da ClienteDAO retornar um objeto Cliente com os seus dados e um objeto Endereco dentro dele?
3- Estou colocando toda a regra de negocio no banco, com procedures, DAO é a melhor opção?
Se vc está colocando toda a regra de negocio no banco (Deus o perdoe por isso ) DAO é realmente a opção correcta. Vc pode ou não colocar um objeto Endereço no Cliente. Depende do ambiente em que usa o cliente e a frequencia com que se precisa consulta o endereço. Vc pode fazer um meio termo usando o lazyloader, ou seja, vc cria o cliente sem o endereço, mas a primeira vez que for pedido o endereço no método getEndereço() vc carrega do banco e guarda. Das proximas chamadas o método retorna direto o objeto sem ir ao banco de novo.
Se um cliente tem um só endereço vc pode fazer um join e trazer as informações do cliente e do endereço ao mesmo tempo. Esta modalidade é boa se vc sempre carrega o endereço quando carrega o cliente.
Se vc não carregar o endereço junto com o cliente então faça dois selects. Um puxa o cliente e outro puxa o endereço. Sim, em dois DAO separados.
Jedi_FeniX
Qual a melhor opção quanto ao select, crio um em cada DAO ou crio um único select na DAO de cliente por exemplo, aonde esta query me retorna os campos de cliente e endereco? Sendo que o meu banco tem mais ou menos uns 500.000 registros.
Valeu pela ajuda, vc esclareceu muita coisa.
sergiotaborda
Jedi_FeniX:
Qual a melhor opção quanto ao select, crio um em cada DAO ou crio um único select na DAO de cliente por exemplo, aonde esta query me retorna os campos de cliente e endereco? Sendo que o meu banco tem mais ou menos uns 500.000 registros.
Valeu pela ajuda, vc esclareceu muita coisa.
Já que vc não está usando os beneficios do OO deixando todas as logicas no banco, o java vai se comportar como um transportador. Deste ponto de vista vc deve pesar a frequencia com que precisa de endereço dado um cliente. Ou seja, vc invoca muitas vezes “cliente.getEndereço()” ? Vc invoca este método sempre que trabalha com cliente ? Provavelmente não. Vc só precisa do endereço para criar NF por exemplo, ou mala posta. Vc não precisa do endereço quando está apenas dizendo que o pedido é do cliente X.
Outra opção é criar dois metodos. Um traz o cliente já com o endereço, e aqui ja usa o join para otimizar.
No outro vc traz o cliente sem o endereço e faz um lazyloading ( se possivel, já que isto depende um pouco da sua arquitetura, mas em web é tranquilo). Ai quando vc sabe que irá precisar do endereço chama clienteDAO.findClientWithAddress(id) quando vc não sabe ou tem a certeza que não precisa usa clienteDao.findClientWithoutAddress(id). Aqui vc pode usar variantes como clienteDao.findClient(id, boolean withAdress).
O DAO serve exatamente para poder criar métodos que consultam o banco de forma diferente conforme o objetivo. O seu caso é o exemplo perfeito desta necessidade.
Jedi_FeniX
Blz, vc está me ajudando para caramaba, valeu pela ajuda…
Agora eu to com dúvida sobre as tabelas de relacionamento, que é n:n. Como ficaria o meu objeto de de transporte? Qual dao iria incluir nela?
Neste exemplo eu tenho a tabela ALUNO relacionada n:n com MATERIA, quem teria o metodo de incluir na tabela de relacionamento? As classes de transporte de Aluno tb teria Materia?
sergiotaborda
Jedi_FeniX:
Blz, vc está me ajudando para caramaba, valeu pela ajuda…
Agora eu to com dúvida sobre as tabelas de relacionamento, que é n:n. Como ficaria o meu objeto de de transporte? Qual dao iria incluir nela?
Neste exemplo eu tenho a tabela ALUNO relacionada n:n com MATERIA, quem teria o metodo de incluir na tabela de relacionamento? As classes de transporte de Aluno tb teria Materia?
Depende. Se a relação é qualificada , ou seja, se a tabela de ligação tem propriedades só dela, então existem 3 objetos Aluno, Materia e InscriçãoAlunoMateria ( ou algo assim) Neste caso vira um 1:n onde vc cria o InscriçãoAlunoMateria(aluno, materia) e sava o InscriçãoAlunoMateria .
Se a relação não é qualificada enão vc tem que escolher uma raiz . ou seja, o que faz mais sentido : adicionar materias ao aluno ou alunos à materia ? E ai vc coloca um addMateria no aluno ou um addAluno na matéria.
Se bem que eu prefiro criar sempre uma terceira entidade porque no caso do sistema vir a precisar de qualificar a relação só aumenta os atributos de InscriçãoAlunoMateria e pronto.
Dependendo da estratégia o DAO correspondente faz o insert. Veja que , o insert sempre será na tabea intermédia mesmo que ela não seja explicita no java ( por isso eu gosto de explicitá-la)
) DAO é realmente a opção correcta. Vc pode ou não colocar um objeto Endereço no Cliente. Depende do ambiente em que usa o cliente e a frequencia com que se precisa consulta o endereço. Vc pode fazer um meio termo usando o lazyloader, ou seja, vc cria o cliente sem o endereço, mas a primeira vez que for pedido o endereço no método getEndereço() vc carrega do banco e guarda. Das proximas chamadas o método retorna direto o objeto sem ir ao banco de novo.