Pessoal,
Aqui no trabalho surgiu uma duvida de como a aplicação deve recuperar objetos complexos do banco de dados.
Considerando o objeto Avô que tem como atributo o objeto Pai, e o Pai tem o objeto Filho.
Temos uma gridview (.net) que é alimentada por uma lista de Avós e nessa grid precisamos exibir os nomes do Avô, do Pai e do Filho.
Usamos um framework criado aqui mesmo que por padrão só monta os objetos até o segundo nivel, ou seja, o Filho sempre vem null.
Sendo assim a lista é montada com apenas um acesso ao banco.
Porem precisamos obter o Filho para todo Avós da lista e isso é feito com um acesso ao banco para cada elemento da lista.
Qual a melhor forma de recuperar esses dados do banco e montar a lista?
Usando um framework ORM (tipo Hibernate), esses dados devem vir sempre que solicitados. Quer dizer, ele fará sempre várias consultas, mas é o preço a se pagar para se ter um framework transparente. Além do mais, esse tipo de overhead pode ser facilmente resolvido com a implementação de caches de dados.
Então um ORM busca o Avô, depois o Pai e depois o filho, fazendo 3 acessos ao banco?
Cache de dados na aplicação ou no banco?
[quote=vangelismm]
Qual a melhor forma de recuperar esses dados do banco e montar a lista?[/quote]
Pela sua explicação parece que cada avó só tem um pai que só tem um filho.
Se isso é verdade crie um objeto que é montado pelos 3 (uma view ) carrege esse objeto directamente por join.
Se cada nivel pode ter vários do nivel abaixo então vc está perante uma relação de arvore. Vc precisa carregar os objetos de uma forma diferente num processo recursivo que carrega toda a arvore. mas isso pode ser muito lento,
portanto normalmente se usa um component de arvore e se carrega os dois primeiros niveis, o terceiro se carrega quando o usuário mandar( apertando o nome do pai, ou algo assim)
[quote=vangelismm]Então um ORM busca o Avô, depois o Pai e depois o filho, fazendo 3 acessos ao banco?
Cache de dados na aplicação ou no banco?[/quote]
Normalmente sim, mas isso pode ser configurável. Costuma ser melhor você fazer três consultas, para não sobrecarregar seu sistema (colocando vários dados na memória de uma só vez). Assim, quando você precisar de alguma informação, ele vai lá e busca, de um jeito transparente.
O cache de dados a que me refiro é feito na aplicação. Um exemplo é o EhCache sob Hibernate, por exemplo. Ele carrega seus dados na memória e atua como um “proxy” na hora de consultar os dados, diminuindo o overhead.