Estou com uma dúvida para representar um relacionamento de tabelas do banco de dados.
Geralmente eu faço uma classe para uma entidade do banco e uma classe DAO que me retorna um List. Esse List é que eu manipulo no meu JFrame.
O negócio é o seguinte… agora eu preciso popular um JTable com um SELECT que faz JOIN em 3 tabelas (e consequentemente 3 classes).
Qual seria a melhor maneira de representar isso?
Não queria manipular um ResultSet no meu JFrame…
Exibir dados de um join em 3 tabelas ou exibir dados de 3 classes relacionadas?
Se o caso for o primeiro , esqueça o MER, procure pensar sempre em objetos e a interação entre eles.
1 (um) SELECT, que retorna um JOIN de 3 (três) tabelas do meu banco, que são representadas por 3 (três) entidades (classes distintas) na minha aplicação.
Como se fosse assim:
Classe: Cliente (Codigo, Nome)
Classe: Vendedor (Codigo, Nome)
Classe: Venda (CodigoCliente, CodigoVendedor, Valor)
Essas seriam minhas classes, e são identicas às tabelas do Banco.
Se eu fosse manipular Clientes (select * from Clientes) por exemplo, eu faria um método para me retornar um List
A minha dúvida é como proceder para manipular uma união entre essas entidades.
Com uma consulta assim:
“select A.NOME, B.NOME, C.VALOR
from CLIENTE A, VENDEDOR B, VENDA C
where (A.CODIGO = C.CODIGOCLIENTE) and
(B.CODIGO = C.CODIGOVENDEDOR)”
A implementacao do seu DAO para Cliente, Vendedor e Venda deve fornecer todo o interfaceamento (de interface) para a sua base de dados, ou seja, se vc implementou o pattern dao, os comandos sql morreram ali. Dai pra frente voce vai lidar com objetos.
No caso, levando em consideracao o seu select, uma venda e composta por um clientge e um vendedor, certo?
Entao faca com o que o dao da venda “monte” o objeto venda completamente (ele sai de la com o objeto cliente e venda ja associado, lembre de utilizar os daos de cliente e vendedor para montar o os respectivos objetos)
//no dao da venda ...
public Venda getById(Sting id){
//select em tabela vendas de acordo com a id e monto o objeto venda
new Venda(parametros aqui)
new daoVendedor()
vendedor = daoVendedor.getById(id que veio do outro select)
venda.setVendedor(vendedotr)
return venda //ja montado completamente
}
Deu pra ver que cansa, ne. Sem contar que existem outros problemas.Coisa do tipo: numa colecao de produtos vendidos, quem esta persistido e quem nao esta? Quem foi alterado?
Neste caso, minha classe venda não deveria ter os atributos “Codigo do Cliente” e “Codigo do Vendedor”, mas sim um atributo que fosse Cliente (da minha classe Cliente).
É isso?
Neste caso eu vejo a necessidade de ter métodos distintos dos “getById” (normais) senão sempre vou fazer SELECTs que pegam todos os campos de forma desnecessária.
Neste exemplo que eu dei por exemplo, um método que devolvesse um objeto “Cliente” só com o “Nome” para preencher meu objeto "Venda.
Isso e não isso.
Se acontecer de um objeto possuir uma coleção muito grande, ou esse objeto possuir outros associados (e cascata vai indo), você não vai querer ter todos eles na memória, nesse caso uma solução possível seria usar lazy load.
Sim , provavelmente você terá muitos outros métodos de busca além do byId, mas eu não sei se é boa idéia devolver um objeto cliente apenas com o nome. Se você tem o nome do camarada é quase certo que foi feita uma busca na tabela dos clientes, porque não pegar logo “tudo” relacionado ao cliente? A diferença entre select field e select field field field field é minima/inexistente.