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?
Desde já agradeço a ajuda!
[quote=Jedi_FeniX]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?
[/quote]
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.
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.
[quote=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. [/quote]
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.
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?
[quote=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?[/quote]
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.