Aqui na empresa, desenvolvemos um OPF (framework de persistência de objetos) que funciona em conjunto com um Gerador de Código que faz o caminho inverso: ele parte do modelo de dados e gera o modelo de classes. Na interface o usuário pode detalhar os relacionamentos entre as classes e fazer mais alguns ajustes, se necessário, mas o foco está no modelo de dados, não no modelo de objetos.
O objetivo principal é o ganho de produtividade: o programador pode usar a feature de "Auto Complete" da IDE, por exemplo, para selecionar propriedades. Erros em nomes de colunas do BD causam erros de *compilação*, aumentando a confiabilidade. O FW também permite carregar o resultado de uma query em uma lista de objetos com propriedades como Count e IndexOf(pk). Nos casos mais simples usa-se o método QueryByTemplate( ); para os casos mais incomuns existe a QueryByFreeSql( ). Havia um flag para ativar o pattern "lazy loading", mas depois de três anos de uso resolvemos tornar essa opção DEFAULT e removemos o flag, porque a diferença de performance é monstruosa. Outra coisa que modificamos foi a carga de colunas binárias, que por default não é feita quando um objeto é instanciado. Comparando com os SELECT's feitos à mão, na maioria dos casos não há diferença de performance. O FW tem inclusive um modo de "debug" que mostra o SQL que foi gerado. Nosso maior problema é educar o programador... por exemplo, se ele quer mostrar uma lista de pedidos com os nomes dos clientes, ele *NÃO* deve fazer uma query na tabela pedidos e depois varrer, dentro do FOR, mandando exibir o conteúdo de lista_pedido[i].Cliente.Nome (pois isso irá gerar um SELECT pra cada pedido), mas SIM fazer uma query em uma view criada especificamente para este fim. Claro que é muito fácil o cara ir digitando "lista_pedido[i]." depois usar o "auto complete" para selecionar "Cliente." e depois "Nome". Mas isso não é nada que não possa ser resolvido com um pouco de treinamento ou com disposição para contratar profissionais mais qualificados (e caros). :-) Em 16/04/08, Leandro DUTRA <[EMAIL PROTECTED]> escreveu: > > 2008/4/15, Nâmio Evangelista <[EMAIL PROTECTED]>: > > > > > Normalmente, problemas como esse acontece quando se tem um programador > ou > > analista desavidado, que acha que o Hibernate é o "rei da cocada > preta"; que > > só basta criar as classes e os seus respectivos arquivos de mapeamente > que > > está tudo tranqüilo. > > > De fato. > > > > > Existe muitas maneiras de otimizar o mapeamento das classes. Um estudo > > detalhado desta modelagem se faz necessário para obter um ganho de > > performance significativo. Tomar os devidos cuidados com relação à > > identidade de objetos é de suma importância para não vir a ter > decepções no > > futuro; saber modelar a cardinalidade e a navegabilidade entre as > > associações de classes também é primordial. > > > Existe uma maneira muito mais simples: faça-se a modelagem dos dados, > e o Hibernate (ou o que mais se for usar) que se adapte a isso. > > Na minha experiência, 'profissionais Hibernate' dificilmente querem se > moldar a um modelo de dados são. > > > > > O problema que o autor deste artigo está enfrentando, eu também passei, > > usando Oracle, quando estava iniciando os trabalhos com Hibernate. A > > diferença é que pesquisei bastante antes de sair falando besteiras a > > respeito da framework. > > > Que autor, que artigo? Que besteiras? Você está respondendo a uma > dúvida de um colega, que não merece ser tratado desse jeito. > > > > > Parto do princípio de que se dentre milhares de pessoas que utilizam > > Hibernate (ou NHibernate), apenas uma, duas ou até dez pessoas falam > > asneiras desta framework, o problema está no profissional e não na > > framework. > > > Primeiro, o que é NHibernate? > > Segundo, leve em consideração que ferramentas não existem no vácuo, > mas têm um caldo de cultura que as acompanham. A cultura Hibernate é > francamente hostil à modelagem de dados. > > > > > Fico a imaginar como este autor se sairia tendo de usar um > banco-de-dados > > como o Caché, DB4O, ou qualquer outro banco-de-dados orientado a > objetos. > > > Justiça seja feita, esses SGBDOOs saem-se relativamente bem com a > estupidez normalmente gerada pelo Hibernate. > > Com o contraponto de que são praticamente inúteis para tudo o mais em > comparação com um SGBD SQL, e que é quase impossível criar outros > programas para usar a mesma base de dados. Relatórios, então… > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL > PROTECTED]> > +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 > +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Atenciosamente, Alexsander da Rosa Linux User #113925
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
