Bom, mas pela argumentação do saoj, trocar o Hibernate por outra solução JPA seria trocar 6 por 1/2 dúzia …[/quote]Até então ele atacou especificamente apenas hibernate… :lol: :lol: :lol:
[quote=Grinvon]P.S.: Alias… estou adorando estudar bancos NoSQL como MongoDB, usando com o Node.JS [/quote]Fiz uma introdução de 2h na Caelum. Também me amarrei, o complicado é realmente achar um lugar que tenha uma aplicação real ao NoSQL. =/
até onde eu trabalhei, seria impossível alterar toda a estrutura de DB.
Bom, mas pela argumentação do saoj, trocar o Hibernate por outra solução JPA seria trocar 6 por 1/2 dúzia …[/quote]
Até então ele atacou especificamente apenas hibernate… :lol: :lol: :lol: [/quote]
Sim, mas qualquer implementação JPA tem as deficiências que o saoj apontou no artigo: você ainda precisa aprenderá uma nova linguagem de query (JPQL), a curva de aprendizado de JPA também é alta, o mapeamento precisa ser feito por anotações e XML, e o programador também não controle sobre quais comandos são executados e quando.
[quote=rmendes08]Sim, mas qualquer implementação JPA tem as deficiências que o saoj apontou no artigo: você ainda precisa aprenderá uma nova linguagem de query (JPQL), a curva de aprendizado de JPA também é alta, o mapeamento precisa ser feito por anotações e XML, e o programador também não controle sobre quais comandos são executados e quando.[/quote]Sim, concordo e discordo mas deixa pra lá.
Eu olho o que está em evidência no mercado. O que indicaria então?
Eu costumo olhar vagas que recebo no email e o que mais vejo é JPA, JDBC e Spring com Mybatis as vezes.
Bem. Infelizmente não existe uma solução perfeita (ainda), enquanto essa solução não chega, eu continuo indo atrás da que me trará mais oportunidade no mercado. [=
[quote=Hebert Coelho][quote=rmendes08]Sim, mas qualquer implementação JPA tem as deficiências que o saoj apontou no artigo: você ainda precisa aprenderá uma nova linguagem de query (JPQL), a curva de aprendizado de JPA também é alta, o mapeamento precisa ser feito por anotações e XML, e o programador também não controle sobre quais comandos são executados e quando.[/quote]Sim, concordo e discordo mas deixa pra lá.
Eu olho o que está em evidência no mercado. O que indicaria então?
Eu costumo olhar vagas que recebo no email e o que mais vejo é JPA, JDBC e Spring com Mybatis as vezes.
Bem. Infelizmente não existe uma solução perfeita (ainda), enquanto essa solução não chega, eu continuo indo atrás da que me trará mais oportunidade no mercado. [=[/quote]
É a velha história, pra dizer se uma ferramente é boa ou ruim depende do contexto, do problema.
Em tempo, eu não tenho nada contra Hibernate ou JPA, mas eu acho os questionamentos do saoj muito válidos. De fato, o framework/especificação traz toda uma complexidade e é preciso colocar na balança se essa complexidade vai compensar em termos de produtividade, é a velha história de querer matar formiga com bazuca.
Agora, para escolher entre as implementações do JPA, eu acho que a melhor opção é usar a implementação que acompanha seu servidor de aplicação. Mas e se for Tomcat ou Jetty ? Nesse caso, talvez seja um indicativo de que um ORM mais simples dará conta do recado.
[quote=rmendes08]É a velha história, pra dizer se uma ferramente é boa ou ruim depende do contexto, do problema.
Em tempo, eu não tenho nada contra Hibernate ou JPA, mas eu acho os questionamentos do saoj muito válidos. De fato, o framework/especificação traz toda uma complexidade e é preciso colocar na balança se essa complexidade vai compensar em termos de produtividade, é a velha história de querer matar formiga com bazuca.
Agora, para escolher entre as implementações do JPA, eu acho que a melhor opção é usar a implementação que acompanha seu servidor de aplicação. Mas e se for Tomcat ou Jetty ? Nesse caso, talvez seja um indicativo de que um ORM mais simples dará conta do recado. [/quote]Pois é né cara, mas me diz uma coisa. Me aponte um framework/ferramenta não que você ao trabalhar não e apareça problemas e coisas que podem ser consideradas como problemáticas?
Até o próprio java é a coisa mais fácil de criticar…
Mas quem disse que o mercado entende das coisas? Olha o passado e vc verá que as ditas soluções padrões do mercado são hoje motivo de chacota.
Se lembra do Struts1 que todo mundo usava? Se lembra do EJB1 que era a grande revolução? Se lembra daquele mundo de XML para configurar qualquer coisa? Até eu achei interessante a primeira vez que eu vi, pois XML era o buzzword mais quente daquela época.
Não estamos discutindo aqui o que vai aumentar a sua empregabilidade no mercado, mas sim o que é mais recomendável e vantajoso para um projeto.
Claro, nada é perfeito. Não é questão de ser melhor ou pior. É uma questão de escolher a FILOSOFIA. O hibernate (e o JPA) não é legal e vão por um caminho equivocado gerando muita complexidade, peso e dores-de-cabeça no longo prazo. Minha opinião.
[quote=saoj]Mas quem disse que o mercado entende das coisas? Olha o passado e vc verá que as ditas soluções padrões do mercado são hoje motivo de chacota.
Se lembra do Struts1 que todo mundo usava? Se lembra do EJB1 que era a grande revolução? Se lembra daquele mundo de XML para configurar qualquer coisa? Até eu achei interessante a primeira vez que eu vi, pois XML era o buzzword mais quente daquela época.
Não estamos discutindo aqui o que vai aumentar a sua empregabilidade no mercado, mas sim o que é mais recomendável e vantajoso para um projeto.
Claro, nada é perfeito. Não é questão de ser melhor ou pior. É uma questão de escolher a FILOSOFIA. O hibernate (e o JPA) não é legal e vão por um caminho equivocado gerando muita complexidade, peso e dores-de-cabeça no longo prazo. Minha opinião.
[/quote]Eu vejo que vantagem para um projeto também é usar um framework onde seja mais fácil encontrar funcionários e um farto material para estudar.
Existem frameworks sendo utilizados onde nem livros são encontrados para estudar…
Bem, mas pelo visto estou desvirtuando o tema do tópico.
Voltando, eu indico o JPA/Hibernate seja lá o que for sim. [=
Concordo que isso é uma vantagem. Mas se vc colocar as vantagens e desvantagens na balança vai ver que essa vantagem que vc citou não paga as inúmeras desvantagens do Hibernate.
E é nesse momento que entra a importância fundamental da simplicidade: vc não treina um cara em hibernate em menos de 6 meses. Mas vc treina um cara em MentaBean em menos de 6 dias.
Vc pode contratar um cara que não sabe MentaBean mas sabe um pouco (ou nada) JDBC e bastante SQL, e ele vai estar up-to-speed em 6 dias com o MentaBean.
Agora contrata um cara que sabe bastante de JDBC e SQL e manda ele assumir um hibernate sem experiência com o Hibernate.
O Hibernate é uma complexidade absurda… transforma o seu sistema numa zona imprevisível. Minha opinião.
[quote=saoj][quote=Hebert Coelho]
Eu vejo que vantagem para um projeto também é usar um framework onde seja mais fácil encontrar funcionários e um farto material para estudar.
Existem frameworks sendo utilizados onde nem livros são encontrados para estudar…
[/quote]
Concordo que isso é uma vantagem. Mas se vc colocar as vantagens e desvantagens na balança vai ver que essa vantagem que vc citou não paga as inúmeras desvantagens do Hibernate.
E é nesse momento que entra a importância fundamental da simplicidade: vc não treina um cara em hibernate em menos de 6 meses. Mas vc treina um cara em MentaBean em menos de 6 dias.
Vc pode contratar um cara que não sabe MentaBean mas sabe um pouco (ou nada) JDBC e bastante SQL, e ele vai estar up-to-speed em 6 dias com o MentaBean.
Agora contrata um cara que sabe bastante de JDBC e SQL e manda ele assumir um hibernate sem experiência com o Hibernate.
O Hibernate é uma complexidade absurda… transforma o seu sistema numa zona imprevisível. Minha opinião.
[/quote]Mas e quanto as vantagens do JPA? Você ve que as desvantagens sobrepõem as vantagens? As faculdades hoje tem formado estudantes com conhecimento básico de JPA então vai começar a chegar juniors com conhecimento básico em JDBC e JPA… Honestamente, não vejo como tamaaaaanha vantagem assim não.
Uma opinião minha: Não seria melhor ensinar os estudantes de banco-de-dados sobre índices, SQL, sharding, joins, transactions, caching, lazy/eager loading, locking, isolation levels, etc. ???
O hibernate tenta abstrair isso com efeitos catastróficos. É mais ou menos como um MAKER da vida. Te permite fazer tudo sem saber nada. Recipe for disaster!
Discordo completamente… iBatis é algo que só serve para select e mais nada.
É um tiro no pé colocar algo tão rudimentar da idade da pedra num projeto grande.
Faço manutenção num sistema grande que usa o Ibatis e ele te limita muito, fora que a documentação
é fraquissima.
[quote=saoj]Uma opinião minha: Não seria melhor ensinar os estudantes de banco-de-dados sobre índices, SQL, sharding, joins, transactions, caching, lazy/eager loading, locking, isolation levels, etc. ???
O hibernate tenta abstrair isso com efeitos catastróficos. É mais ou menos como um MAKER da vida. Te permite fazer tudo sem saber nada. Recipe for disaster! [/quote]E por que não os dois? Ao invés de 100% em uma ferramenta apenas, melhor seria 50% em cada. Desse modo um aluno teria mais chance de conseguir o primeiro emprego do que ter seu foco em apenas uma tecnologia.
O que eu acho ruim no hibernate/JPA é a intrusão no código… Como utilizá-lo em um sistema legado ou para interagir com um?
É difícil trabalhar de forma “híbrida” com ele… Ou seja, quero usá-lo para um módulo novo, mas preciso manter o que está hoje sem alterações… Não vejo uma forma “amigável” de fazer isso com hibernate…
E outra, já vi vários tópicos do tipo:
E eu me pergunto… O cara tem a solução na mão (a própria SQL), mas deve traduzir isso para que o framework entenda? :shock:
[quote=erico_kl]O que eu acho ruim no hibernate/JPA é a intrusão no código… Como utilizá-lo em um sistema legado ou para interagir com um?
É difícil trabalhar de forma “híbrida” com ele… Ou seja, quero usá-lo para um módulo novo, mas preciso manter o que está hoje sem alterações… Não vejo uma forma “amigável” de fazer isso com hibernate…
E outra, já vi vários tópicos do tipo:
E eu me pergunto… O cara tem a solução na mão (a própria SQL), mas deve traduzir isso para que o framework entenda? :shock:
embaçado…[/quote]Como digo… falta entender a ferramente.
JPA dá suporte a bancos já existentes… Não precisa ser um DB legal.
Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.
O mapeamento pode ser feito em xml para que o código não seja intrusivo…
Nem sempre a decisão da equipe vai ser pelo que for melhor tecnicamente, vários outros fatores podem pesar mais como já falado por aqui, como o fator mercado, isso de fato pesa.
Hibernate se torna problema dependendo do uso, ele não tem só canhão, tem armas leves também. Na equipe que trabalho lidamos com cada tipo de situação, aplicando o recurso mais adequado dentro do Hibernate, seja ele “normal”, stateless ou uso de SQL nativo mapeado. Essas são as principais possibilidades que devem ser exploradas e não só ficar no uso do hibernate de forma padrão para todos os casos.
Achei ótimo alguns itens que escreveu e respeito as demais críticas. Concordo que o Hibernate do Java ainda é muito tosco na parte de mapeamento, onde é feito com gambiarra (amarrado com annotations) ou o velho XML. E a linguagem de consulta de objetos fica ilegível em situações complexas e stringada demais nas propriedades, onde é melhor usar SQL mesmo. Mas ao mesmo tempo não entendo por que o povo do Java não copia as melhorias feitas no NHibernate, como mapeamento programático e QueryOver.
Sobre tanto falar para usar SQL ao invés de consulta em objetos, você mesmo sabe que isso é opcional no hibernate, então cada time entra em consenso do que vai ajudar mais num projeto ou situação.
Sei que tem empresas ainda que aplicam a ditadura do purismo, mas fujam disso.
Aí vem aquela velha história… Realmente preciso me preocupar com mudança de banco no meio do projeto? Isso vai ser algo tão trivial assim? Se sim, somente com JPA terei suporte a diferentes dialetos?
As duas primeiras perguntas somente o contexto do meu projeto que vai responder.
Certo, só aí não consigo ver a vantagem do framework.
Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.[/quote]
Certo, só aí não consigo ver a vantagem do framework…[/quote]
A vantagem é ter a possibilidade de usar SQL em situacoes especiais, como relatorios. Isso nao vai tirar as vantagens dos principais recursos do hibernate para situacoes rotineiras de SQL.
Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.[/quote]
Certo, só aí não consigo ver a vantagem do framework…[/quote]
A vantagem é ter a possibilidade de usar SQL em situacoes especiais, como relatorios. Isso nao vai tirar as vantagens dos principais recursos do hibernate para situacoes rotineiras de SQL.[/quote]
Eu não me referia à vantagem de usar SQL pura, mas sim a vantagem de usar SQL pura com o Hibernate. Quando se faz isso vc consegue aproveitar todo o mepamento já criado?
Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.[/quote]
Certo, só aí não consigo ver a vantagem do framework…[/quote]
A vantagem é ter a possibilidade de usar SQL em situacoes especiais, como relatorios. Isso nao vai tirar as vantagens dos principais recursos do hibernate para situacoes rotineiras de SQL.[/quote]
Eu não me referia à vantagem de usar SQL pura, mas sim a vantagem de usar SQL pura com o Hibernate. Quando se faz isso vc consegue aproveitar todo o mepamento já criado?[/quote]
[/quote]Fiz uma introdução de 2h na Caelum. Também me amarrei, o complicado é realmente achar um lugar que tenha uma aplicação real ao NoSQL. =/