Olá a todos, gostaria de opinião de vocês para ajudar a resolver um problema que enfrento hoje, o cenário e o seguinte:
Trabalho em uma empresa que possue um ERP feito em Delphi, e utilizado o SGBD Firebird, o sistema é enorme chegando a ter quase 200 tabelas no banco de dados, a maioria das funcionalidades e feita através de procedures armazenadas no banco, como gravação de titulos, e ate mesmo cadastros como de cliente.Pois bem, a empresa quer passar uma parte do sistema pra WEB, utilizando Java, no inicio decidi usar Hibernate pois o prazo e curto e o Hibernate me da um ganho de produção enorme, mas no decorrer do projeto, tive que pegar um Generator do firebird, tentei fazer desta maneira:
Query query=em.createNativeQuery("Select gen_id(nome_do_generator,1) from rdb$database");
count=query.getSingleResult();
Mas o drive do Firebird me lança um erro de CHARACTER_LENGTH, então tive que usar JDBC na mão criando uma outra camada de Persistencia, trabalhando agora com Connection e PreparedStatement, com JDBC consegui fazer funcionar perfeito, mas tenho o problema de usar duas “camadas” e não gostei desta abordagem.
Gostaria da opinião de você, alguem que ja tenha experiencia com Bancos de Dados legado pra saber se vale a pena usar o Hibernate neste caso ou e melhor usar JDBC puro e perder um pouco mais de tempo fazendo os mapeamentos na mão.
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.
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.
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
[quote=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 ;)[/quote]
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.
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.
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.[/quote]
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.
