Boa noite pessoal,
Estou desenvolvendo um projeto em java e para não ter que ficar escrevendo sql para o CRUD de cada bean, eu criei uma classe que lê os beans e gera as instruções dinamicamente, fiz isso usando reflection. Alguém sabe se o uso de reflection para analisar um bean custa muito em termos de processamento para a jvm ?
Porque reinventar a roda?
Use o Hibernate amigo…
Quanto ao uso da api de reflexão, já ví muita gente falar aqui no fórum que o desempenho da mesma não é bom, mas não sei te dizer o quão lento isso pode ser ou se mesmo pode atrapalhar na execução de sua aplicação.
Até mais!
[quote=FernandoLima]Boa noite pessoal,
Estou desenvolvendo um projeto em java e para não ter que ficar escrevendo sql para o CRUD de cada bean, eu criei uma classe que lê os beans e gera as instruções dinamicamente, fiz isso usando reflection. Alguém sabe se o uso de reflection para analisar um bean custa muito em termos de processamento para a jvm ?[/quote]
A conta que vc deve fazer não é se pesa na JVM (ela já é grandinha e sabe cuidar de si) A pergunta é: o que é mais simples : criar umas classes que geram SQL via Reflection e usá-las vezes sem conta ou criar strings SQL na mão vezes sem conta ? 
haha você fez uma pergunta e ganhou duas opiniões!
já que ninguém te respondeu, vou tentar dar uma sugestão: tenta fazer um testezinho de stress “na mão”. aquele clássico de calcular os milissegundos, faz uma boa quantidade de chamadas do teu código e vê quanto tempo levou.
leve em consideração em que ambiente vc vai rodar tua aplicação (web, desktop…) e tira uma base.
acho que pode ser algo próximo do que você quer saber.
[]s
Pessoal, obrigado pelas respostas!
Nós optamos por não usar o Hibernate porque nós nunca usamos ele antes, e esse projeto nós temos que entregar num prazo muito curto, então achamos que não daria tempo de estudar bem o Hibernate, afinal, em projetos comerciais não dá pra usar um framework sem saber exatamente como lidar com suas vantagens e desvantangens, por isso optamos por elaborar uma classe que gera as SQLs com base nos beans.
Obrigado a todos pela colaboração, foi de grande valor. Agora a gente conseguiu refletir melhor sobre essa questão.
Até mais !
[quote=FernandoLima]Pessoal, obrigado pelas respostas!
Nós optamos por não usar o Hibernate porque nós nunca usamos ele antes, e esse projeto nós temos que entregar num prazo muito curto, então achamos que não daria tempo de estudar bem o Hibernate, afinal, em projetos comerciais não dá pra usar um framework sem saber exatamente como lidar com suas vantagens e desvantangens, por isso optamos por elaborar uma classe que gera as SQLs com base nos beans. [/quote]
Estranho, você não tem tempo de aprender o Hibernate mas pode gastar tempo reinventando a roda escrevendo um esquema de reflection que provavelmente é furado em diversos casos (como você trata associações? e herança?). Na boa, é muito mais perigoso pro seu projeto comercial o que você está fazendo do que ir aprender a usar o Hibernte e usar ele.
Invocar um método (ou contrutor) e acessr um campo usando reflexão é sempre mais lento do que fazer isso estaticamente, mas normalmente esse custo não é “visível” dentro do sistema. Você só vai notar que reflexão está lhe custando alguma coisa se precisar de um sistema que rode em tempo real e que deva obrigatoriamente ter uma performance absurda, o que não é, nem de longe, comum (e também não é muito inteligente fazer um sistema desses em java…).
O que você pode fazer, é fazer como o Hibernate faz (tá vendo…) ler as classes e gerar os comandos básicos (SELECT, UPDATE, INSERT e DELETE) na inicialização e guardar os objetos Method, Constructor e Fields conrrespondentes de cada objeto, para evitar ter que buscar eles sempre que eles forem necessários, por que isso sim pode impactar na performance da aplicação.
Mas, só pra ser mais enfático ainda, não perca tempo com isso, “fazer” uma ferramenta ORM ou que facilite o acesso a bancos de dados não é trivial, na verdade não deveria nem ser considerado com a quantidade de ferramentas pra se fazer isso que existem em java.