A independencia de banco de dados vai para o quiabo, se é que algúem deva ser preocupar com isso.[/quote]
Nesse ponto eu concordo contigo,esse argumento da portabilidade é um daqueles que eu nunca vi(e nem conheço) ser usado na prática.
Mas queria levantar o seguinte ponto:Pq não tentar usar o melhor dos 2 mundos(deixar o Hibernate/JPA fazer bem o que ele sabe e resolver caso-a caso esses problemas pontuais?
Eu,por exemplo,gosto muito da facilidade que o Hibernate me proporciona(Anotattions,Api de Criteria,Projections etc) mas não hesito em deixá-lo de lado nos(poucos) casos onde ele mais me atrapalha do que ajuda.
É bom saber que existem outros que mesmo conhecendo as tecnologias vigentes e utilizadas pelo mercado é aberto a novas tecnologias.
É gente assim que abre caminho para a maioria de nós pequenos programadores.
Go ahead!!!
Todo mundo começa pequeno e enfrentando multidões.
Não é porque a maioria come coco (infelizmente come) que eu vou comer também não é?
A ideia de padronizar as ferramentas para ORM e exigi-las como criterio para avaliação de conhecimento é que não me soa muito interessante.
É direito de escolha de todo desenvolvedor decidir e opinar quais fundações são melhores para seus projetos.
Como eu disse no post acima, hibernete não é ruim, mas não dá pra me engessar nele.
Acho que o essencial é sempre buscar ter conhecimento de banco e ter BOM SENSO. Por exemplo, se a pessoa deixar as queries sendo exibidas no console e tiver o costume de acompanhá-las, mesmo que uma vez ou outra, pode otimizar suas consultas, fazendo queries específicas quando for o caso, evitando tráfego pesado e desnecessário.
Só não gosto quando usam Hibernate como se fosse bala de prata. Hibernate é muito bom pra maioria dos casos, mas pra relatórios e consultas complexas uso SQL nativo, o próprio hibernate é aberto a isso através de named querys.
Eu trabalhava com desenvolvimento, usava Hibernate, mas já faz uns 4 anos e mudei de área. Na minha nova área, estou precisando fazer uma aplicação SIMPLES que necessita comunicar com um banco de dados já existente. Ou seja, não preciso e nem pretendo fazer nada muito complexo. Meu conhecimento anterior já está desatualizado e mais fraco.
Acredito que seja um pouco mais dificil de mapear do que quando o banco é gerado pelas anotações do Hibernate.
Quais dessas opcões vocês me aconselham a usar?
JDBC puro, Hibernate com SQL … etc…
Ou ainda é possível eu mapear o banco, sem te-lo que excluir e recriar e usar HQL.
Eu trabalhava com desenvolvimento, usava Hibernate, mas já faz uns 4 anos e mudei de área. Na minha nova área, estou precisando fazer uma aplicação SIMPLES que necessita comunicar com um banco de dados já existente. Ou seja, não preciso e nem pretendo fazer nada muito complexo. Meu conhecimento anterior já está desatualizado e mais fraco.
Acredito que seja um pouco mais dificil de mapear do que quando o banco é gerado pelas anotações do Hibernate.
Quais dessas opcões vocês me aconselham a usar?
JDBC puro, Hibernate com SQL … etc…
Ou ainda é possível eu mapear o banco, sem te-lo que excluir e recriar e usar HQL.
Aguardo sugestões, muito obrigado.[/quote]
Não precisa excluir nem recriar as tabelas, é só não usar a parte de criação de schema. No mapeamento vai rolar as adaptações para o seu modelo de classes x tabelas do legado no banco, mas se quiser mapear igual a tabela fica a seu critério.
O sistema terá muitos CRUDs? Se tiver é vantagem usar Hibernate. E quando é um sistema que predomina consultas e relatórios, melhor SQL puro. Se for as duas coisas usa Hibernate e SQL através do próprio Hibernate quando necessário.
É que eu estava meio preocupado em ter que estudar de novo, banco de dados para criar a sincronização com as Annotations do Hiber.
Então, veio a dúvida, se as vezes compensava usar SQL puro.
Porém, com o receio de que o banco possar crescer em tamanho e complexidade, acho que já vou deixar preparado para o Hibernate.
A discussão é interessante, mas toda Framework tem sua vantagem e desvantagem.
O melhor mesmo é possuir um bom conhecimento em uma linguagem de programação, sendo ela também em banco de dados e usar desse conhecimento para se criar uma Framework própria.
Eu mesmo desenvolvi uma Framework de banco de dados própria onde através da criação das tabelas todo o código java para criação de Daos, Beans e Visões são gerados a partir das classes, mas claro que nem tudo será feito automaticamente, existem particularidades, cada caso é um caso.
O importante é o resultado final, onde uma aplicação é gerada, ficando a cargo do desenvolvedor(No caso eu) ajustar alguns pontos.