[quote=rafoli]Tenho uma aplicação feita a muito tempo em delphi onde coloquei quase toda a lógica da aplicação no BD por store procedures e triggers, ou seja quase nada no Delphi de codificação…
Vejo um caso on não se faz necessário a utilização do hibernate, no caso de uma migração por exemplo de Delphi para Java…
[/quote]
Depende. Você vai migrar a aplicação sem muito esforço, do tipo pegar a linahd e código Delphi e transformar em Java ou vai migrar o apradigma? Eu não sou especialista em Delphi para saber o que dá ou não para fazer mas supondo que estas sejam as melhores técnicas na plataforma elas ainda assim não o são na plataforma Java. Em Java você deveria realmente repensar essa arquitetura, você não vai tirar muito proveito da paltaforam desta maneira (provavelmnte é melhor continuar no Delphi).
E como eu falei sem números e contexto isso não quer dizer nada.
então você entendeu o que eu quis dizer ao vinnymaran, para alguns casos como o do meu exemplo talvez trazer a lógica do BD pro Java não se faz necessário, por exemplo, se quiser colocar uma camada de apresentação na Web, e com isso o Hibernate não é uma boa opção…
Para futuros projetos o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO…
Hoje não coloco funcionalidades em quase sua totalidade no BD como no exemplo do Delphi…visto que a aparente melhora de desempenho pode trazer diversos malefícios em relação a continuidade do software e sua evolução…
então você entendeu o que eu quis dizer ao vinnymaran, para alguns casos como o do meu exemplo talvez trazer a lógica do BD pro Java não se faz necessário, por exemplo, se quiser colocar uma camada de apresentação na Web, e com isso o Hibernate não é uma boa opção…
[/quote]
Isso não faz o menor sentido. Se você pretende mudar uma aplicação de Delphi/VB/Oracle Forms/[coloque_aqui_sua_tecnologia_do_milênio_passado_favorita] para Java/.NET, não faz o menor sentido manter a arquitetura antiga na plataforma nova, ainda mais se você pretender fazer uma aplicação com múltiplas camadas de apresentação. Além do mais, apesar de ser uma prática comum, manter lógica de negócios no banco de dados na forma de stored procedures e/ou usar o banco de dados para fazer qualquer tipo de integração entre aplicações são estratégias bem pouco efetivas para se projetar um software, sob qualquer aspecto.
E migrar de plataforma tecnológica não é um projeto NOVO?
" Para futuros projetos o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO… "
se antes eu disse que não compenssa pra esse exemplo visto que está a muito tempo em uso e funcionando perfeitamente, não se faz necessário mudar a lógica implementado no BD para a lógica implementada em Java
ou seja, nesse caso DEIXA QUETO, e para projetos futuros ai vem a frase "…o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO… "
" Para futuros projetos o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO… "
se antes eu disse que não compenssa pra esse exemplo visto que está a muito tempo em uso e funcionando perfeitamente, não se faz necessário mudar a lógica implementado no BD para a lógica implementada em Java
ou seja, nesse caso DEIXA QUETO, e para projetos futuros ai vem a frase "…o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO… "
Abraços
Rafael Oliveira[/quote]
Eu que digo que “tá difícil”. Se funciona tão perfeitamente assim, por que diabos você vai querer perder tempo migrando tudo para Java? Se você pretende montar uma outra aplicação (digamos que uma webapp) e pretende usar banco de dados como meio de integração, sinto muito, mas você está pelo menos uns 15 anos atrasado em estratégia de integração e acho que o mundo inteiro sabe que fazer integração através de banco de dados é um imenso desastre!
onde eu disse que é vantagem ou eu to migrando alguma coisa pra Java???..vc se pedeu na discussão
o vinnymaran perguntou “Quando usar hibernate?”…
daí eu disse que POR EXEMPLO num projeto de migração onde a lógica esta no BD não é um bom caso visto que transferir a lógica pra Java e mapear o BD pro Hibernate é custoso o que a depender do caso não compensa…ou então se optar pro mapear usando o recurso sql-query do hibernate pra executar as store procedures perde-se agora em desempenho, ou seja NESSE caso não aconselho…mas cada caso é cada caso…
Para projetos futuros aconselho a ele utilizar visto que vai se beneficiar do Hibernate ganhando em produtividade, manutenção e reusabilidade…
Não me perdi, eu entendi muito bem seu exemplo como suposição e não como caso real, mas eu estou discutindo aqui o valor da sua suposição e, sim, ainda continuo discordando da sua suposição
BTW, você poderia citar um caso em que mapear as suas entidades para o Hibernate pode ser tão custoso assim que não valha a pena?
eu disse que CUSTOSO é mudar a lógica implementada no BD pra uma implementação em JAVA…ou seja, tempo, horas de trabalho, dinheiro, etc
e em relação a MAPEAR perde-se em desempenho, visto que é mais uma camada…
e ainda digo que CADA CASO é CADA CASO…ou seja tudo isso que eu digo pra uma aplicação pode ser insignificante, em relação ao custo gerado e desempenho alterado, e com isso compense mudar a arquitetura…
Sem entrar na discussão de vcs, acabei de fazer um sistema web para emissão de relatórios dinâmicos utilizando jasperreports + spring. Como o sistema só faz montar querys de acordo com os filtros informados para depois montar a view do relatório, eu acabei montando as querys “na mão” utilizando o DBUtils da Apache. Achei que ficou bem simples, não precisei utilizar o hibernate apenas para fazer os selects.
Daniel, acho que essa aplicação possa servir de exemplo para sua pergunta.
[quote=marvera]Sem entrar na discussão de vcs, acabei de fazer um sistema web para emissão de relatórios dinâmicos utilizando jasperreports + spring. Como o sistema só faz montar querys de acordo com os filtros informados para depois montar a view do relatório, eu acabei montando as querys “na mão” utilizando o DBUtils da Apache. Achei que ficou bem simples, não precisei utilizar o hibernate apenas para fazer os selects.
Daniel, acho que essa aplicação possa servir de exemplo para sua pergunta.
Att,
Marcus.[/quote]
Acho q eh por ai mesmo.
Eu soh vejo utilidade no hibernate qdo vc se depara com o tar do impedance mismatch, onde seria um parto mapear suas classes para o banco de dados. Nesse caso o ganho de uma ferramenta de mapeamento compensa qqr perda q ela possa ter em porformance.
Em paradigmas procedurais, q ainda eh maioria hj em dia, nao vejo pq nao escrever as sqls na mao, ja q o modelo das classes e o do BD eh bem parecido.
Se vc tem um paradigma procedural, como você tem modelo de classes?[/quote]
Nao eh o fato de existirem classes q faz com q seja orientado a objeto. Todo mundo q escreveu codigo em Delphi, por exemplo, ao escrever os eventos esta na verdade escrevendo metodos em uma classe - o TForm -mesmo q o cara nao soubesse disso. Mas nao eh por isso q vamos dizer q aquilo eh orientacao a objeto.
Eu ja vi modelos de classes q eram um espelho fiel do BD - ou vice-versa - com chave estrangeira e tudo. Nesses casos q eu digo: pra que hibernate? So pra ter uma coisa a mais pra se preocupar na hora de dar manutencao?
Ou tenta - quando necessario - fazer um modelo de dominio da melhor maneira possivel, a ai o hibernate ou qqr framework de mapeamento O-R é quase q obrigatorio. Ou segue na linguagem estruturada que nao precisa de mapeamento.
Realmente, casos de migracao devem ser analisados a parte, pois existem aqueles que e mais rapido copiar a query e jogar no java do que fazer o mapeamento.
De qualquer forma, sou da mesma opiniao da menina que postou anteriormente, vai depender do conhecimento de cada um, nao adianta por tudo em hibernate porque e da moda se vc nao sabe o que esta fazendo, pois podem ocorrer problemas e voce deve estar preparado.
Apenas para reforcar, sou da opiniao que se vc nao sabe e nao tem tempo para aprender. nao use, a empresa agradece.
Tenho uns projetos só com consultas com SQLs com muitas linhas (mais de mil é comum), com join de dezenas de tabelas, usando vários agrupamentos, etc e tal. Só consulta desse tipo.
Basicamente não há domínio de objetos, já que as telas normalmente apenas refletem o resultado das consultas. Não preciso de lazy loading, cache, criteria API só ia complicar a minha vida, não faço CRUD, por aí vai. Nesses casos, prefiro usar JDBC normal… pra todos os outros, prefiro Hibernate.
Diante dos benefícios citados quanto ao uso do hibernate, em que situações vocês se vêem utilizando JPA ou iBATIS, ou seja, mediante decisões de projeto quando eu devo ou não utilizar estes três frameworks citados?
Abraços