Opiniao sobre a escolha da camada de persistencia

Vc teve que pegar esse generator na mão… Por causa de uma regra de negócio sua?

A annotation @GeneratedValue não te ajuda a obter esse valor?

Ola Ignacio a notacao @GeneratedValue nao funcionou para o Firebird, pode ter sido algum erro meu mas nao consegui fazer funcionar, embora em outros bancos funciona perfeito como MySQL no firebird nao funciona.

Deixa eu me meter nesta?

Muitos podem não concordar comigo mas ORMs são mais indicados para projetos que NÃO ENVOLVEM LEGADOS, portanto nesta condição o mais indicado seria a utilização do JDBC (diretamente) ou no máximo o iBATES. Existem algumas justificativas para isto, mas no seu caso uma que eu acho boa é o fato de vc poder reaproveitar a procariada toda (triggers, procedures, funções, views etc…) que estão sob o domínio do banco de dados.

flws

Agreed… não que seja “inerentemente” impossível usar em um projeto “legado”, mas a maioria dos projetos “legados” não tem suas entidades bem escritas… é ID pra lá, ID pra cá, classe representando relacionamentos N-N “simples”…

Concordando com o Fantomas e com o Rubem, mas citando outro problema que pode surgir usando hibernate…
Como você mesmo disse, existem regras em procedures, se utilizar hibernate você vai “duplicar” essas regras, ou seja, qualquer alteração sempre vai ter dois lugares para alterar ou pior, vai esquecer de um

reinaldob:

Concordando com o Fantomas e com o Rubem, mas citando outro problema que pode surgir usando hibernate…
Como você mesmo disse, existem regras em procedures, se utilizar hibernate você vai “duplicar” essas regras, ou seja, qualquer alteração sempre vai ter dois lugares para alterar ou pior, vai esquecer de um ;)

Eu ja tinha pensado nisso. Neste ponto tenho duas alternativas ou duplico as regras e faço meu modelo ficar “rico” ou somente executo as procedures e pego os retornos. O problema de somente executar as procedures e que meu modelo fica muito pobre ou seja fica “anemico” minhas classes nao sao nada mais do que structs de luxo, mas pelo outro lado se eu duplicar as rotinas, como voce observou fica dificil de manter, sem contar que existem rotinas extramamente complexas envolvendo calculo de juros por grupo de produto e convenio, que levaria bastante tempo para serem implementadas.

Por enquanto estou mais convecido de usar JDBC puro e aproveitar as regras do banco, pois se por um lado meu trabalho e maior de mapear por outro tenha as regras de negocio pronta.

Valeu

Concordo plenamente com o fantomas.

Alias, nao sei se é o caso do Daniel, mas as empresas nao perdem a maldita mania de por programador Delphi pra migrar aplicacoes para Java. Nao que programador Delphi seja necessariamente ruim, mas sao filosofias e metodos de desenvolvimento diferentes. Essa atitude no fim das contas é mais cara, porque é mais demorada e invariavelmente tem um resultado bem aquem do esperado, (so como exemplo, eu cansei de ver classes “Utils”, repleta de metodos estaticos com exatamente os mesmos nomes das funcoes do Delphi).

Nao estou dizendo que programador Delphi é pior que programador Java, ou qualquer coisa do tipo, só que tem filosofias de desenvolvimento diferentes e tem suas arquiteturas preparadas baseadas nessa filosofia. Por isso que javeiro costuma dizer que Delphi é pra noob e delpheiro dizer que java nao eh produtivo. Mas na verdade sao apenas diferentes.

Daniel, se voce nao tiver experiencia profissional em Java, sugira a seu gerente contratar um desenvolvedor que tenha. Por maior que possa ser o salario, ficara mais barato porque levara menos tempo, e de quebra os outros desenvolvedores nao precisam sofrer os problemas comuns de quem esta migrando para java.

Reforçando apenas: Mesmo nao sendo o caso desse topico é uma pratica muito comum dos gerentes, se nao for o seu caso, Daniel, nao leve a mal.

YvGa:

Concordo plenamente com o fantomas.

Alias, nao sei se é o caso do Daniel, mas as empresas nao perdem a maldita mania de por programador Delphi pra migrar aplicacoes para Java. Nao que programador Delphi seja necessariamente ruim, mas sao filosofias e metodos de desenvolvimento diferentes. Essa atitude no fim das contas é mais cara, porque é mais demorada e invariavelmente tem um resultado bem aquem do esperado, (so como exemplo, eu cansei de ver classes “Utils”, repleta de metodos estaticos com exatamente os mesmos nomes das funcoes do Delphi).

Nao estou dizendo que programador Delphi é pior que programador Java, ou qualquer coisa do tipo, só que tem filosofias de desenvolvimento diferentes e tem suas arquiteturas preparadas baseadas nessa filosofia. Por isso que javeiro costuma dizer que Delphi é pra noob e delpheiro dizer que java nao eh produtivo. Mas na verdade sao apenas diferentes.

Daniel, se voce nao tiver experiencia profissional em Java, sugira a seu gerente contratar um desenvolvedor que tenha. Por maior que possa ser o salario, ficara mais barato porque levara menos tempo, e de quebra os outros desenvolvedores nao precisam sofrer os problemas comuns de quem esta migrando para java.

Reforçando apenas: Mesmo nao sendo o caso desse topico é uma pratica muito comum dos gerentes, se nao for o seu caso, Daniel, nao leve a mal.

Olá não é o meu caso eu nunca programei em Delphi, programo em Java há mais ou menos uns 2 anos, antes de Java programava em C. Mas o problema todo do sistema é que não posso ter um modelo rico como disse acima, então a camada de persistencia com Hibernate não iria me adiantar muita coisa, visto que as regras de negocio estão no banco, por isso optei por JDBC.

Falow