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.
E aí vc perde o refactoring…[/quote]
Sim, com JPA você terá suporte a diferentes dialetos. Já trabalhei em aplicações que rodavam em 4 bancos diferentes, todas usando a mesma JPQL.
Uma vantagem é produtividade. Imagine uma query que traga uma classe com 40 campos e dois relacionamentos com 20 campos cada… Haja animo para montar o resultado dessa query do JDBC… get/set para cada campo, loops e assim vai. JPA você pode criar um objeto só para uma query de relatório e apontar para uma classe pronto. Outra vantagem é que você pode usar da vantagem nativa do banco de dados, alguma função específica. A maioria das aplicações rodam em cima de um banco apenas que eu já trabalhei, então pra que se preocupar em portabilidade? Usa a NativeQuery se esse é o problema…
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]
Falai cara. É exatamente sobre usar SQL pura com Hibernate que eu quis dizer, nada fora dele. Seria named query nativa por exemplo e também o Transformer como o Arthur F. Ferreira falou (funciona bem nos casos mais comuns, só é necessário na classe seguir corretamente o tipo de cada propriedade em relação ao que o banco vai trazer, pois ele faz o mapeamento automaticamente). Então opções não faltam.
Só não entendi sobre “aproveitar mapeamento já criado”, mas me refiro com algo já planejado em que você cria uma classe enxuta dedicada a query do relatório.
Exemplo qualquer:
<sql-query name="QueryResultadoVenda">
<return class="pacote.ResultadoVenda"/>
<![CDATA[
select
rownum as id,
campo1,
campo2
from
tabela
where
campo3 = :parametro
]]>
</sql-query>
Então para cada tipo de problema use a arma adequada dentro do próprio framework.
Não duvidei do suporte à diferentes dialetos, na verdade acho isso algo bem interessante. O que quis levantar foi: SOMENTE com JPA que terei suporte à outros bancos? E a resposta é: Não.
Este ganho na produtividade existe em outros frameworks também, e nem por isso precisam fazer “mágica” pra isso. O exemplo que mais posso argumentar é o caso do MentaBean… Você monta a sql como quiser e nem por isso precisa percorrer o ResultSet manualmente para formar a lista de retorno, não importa o quão complexa seja a query.
O xml não fica “preso ao fonte”. Como a configuração não é programática, a cada alteração na sua camada de negócios (inclusão, alteração ou remoção de alguma propriedade), você deve catar a respectiva configuração no xml e alterar lá também. Ou seja, vc perde uma grande vantagem: refatoração.
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]
Falai cara. É exatamente sobre usar SQL pura com Hibernate que eu quis dizer, nada fora dele. Seria named query nativa por exemplo e também o Transformer como o Arthur F. Ferreira falou (funciona bem nos casos mais comuns, só é necessário na classe seguir corretamente o tipo de cada propriedade em relação ao que o banco vai trazer, pois ele faz o mapeamento automaticamente). Então opções não faltam.
Só não entendi sobre “aproveitar mapeamento já criado”, mas me refiro com algo já planejado em que você cria uma classe enxuta dedicada a query do relatório.
Exemplo qualquer:
<sql-query name="QueryResultadoVenda">
<return class="pacote.ResultadoVenda"/>
<![CDATA[
select
rownum as id,
campo1,
campo2
from
tabela
where
campo3 = :parametro
]]>
</sql-query>
Então para cada tipo de problema use a arma adequada dentro do próprio framework.[/quote]
Me corrija se eu estiver errado, você fala de Named Queries, aquelas sqls que podem ficar tanto no XML como na sua classe de negócios?
Se usando sql nativa no hibernate você constrói a sql da maneira que quiser (em tempo de execução) e pega os dados a partir do mapeamento criado (no xml ou via annotation).
Sim, no XML ou via código através de createSQLQuery + Transformer num Repositorio específico. Na classe de negócios você diz entidade com aqueles mapeamentos por annotations? Eu particularmente não gosto, por além de amarrar outros recursos e misturar as coisas, é confuso demais de ver, gosto de olhar a entidade puramente, assim é mais fácil de entender o negócio. Mas se uma equipe decidir que vai ser mais prático assim e teve experiencia de sucesso, então que se respeite.
Uma coisa vocês tem razao, Hibernate (do Java) parou no tempo, sentou no sucesso, tá na hora de acordar e ter mapeamento programático, pois no NHibernate do .NET é tudo perfeito nesse aspecto, por isso eu gosto tanto e seria muito bom ter isso no Java também.
Por fim, seja lá qual for opção, vai poder usar SQL do jeito que quiser mesmo, e o resultado será automaticamente populado em uma lista de uma classe, ou um valor direto no caso de query scalar.
Desde o início que eu vi que não prestava. Minha principal crítica é a falta total de controle que vc tem em cima do framework.
Why the Hibernate learning curve is so big? Why does Hibernate do so many things automagically that I cannot control or understand?
When I check the Java questions in a forum or discussion list I can?t help but notice that a lot of them are about Hibernate. Hibernate can have some qualities but ?persistency that just works? is not one of them. It often does not work or works in ways you could have never imagined. I must agree with what Pascal Thivent says here: ?Hibernate in the wrong hands can be a real disaster!?. Below I list another examples of Hibernate surprising behaviors:
Do people really think that without Hibernate you have to write a lot of SQL and JDBC boilerplate?
People who think like that were probably so busy learning Hibernate that they missed the alternative movement of query builders or worse, don?t understand the wonders that reflection, proxies and abstraction can do to simplify things. Check the code below which performs a SQL query:
Connection conn = getConnection();
BeanSession session = getBeanSession(conn);
PreparedStatement stmt = null;
ResultSet rset = null;
try {
StringBuilder sql = new StringBuilder(1024);
sql.append("select ");
sql.append(session.buildSelect(User.class));
sql.append(" where status = ? and deleted = ?");
stmt = SQLUtils.prepare(conn, sql.toString(), Status.GOLD.toString(), 1);
rset = stmt.executeQuery();
List<User> users = new LinkedList<User>();
while(rset.next()) {
User u = new User();
session.populateBean(rset, u);
users.add(u);
}
System.out.println("Total de usuários carregados: " + users.size());
} finally {
SQLUtils.close(rset, stmt, conn);
}
Sim, no XML ou via código através de createSQLQuery + Transformer num Repositorio específico. Na classe de negócios você diz entidade com aqueles mapeamentos por annotations? Eu particularmente não gosto, por além de amarrar outros recursos e misturar as coisas, é confuso demais de ver, gosto de olhar a entidade puramente, assim é mais fácil de entender o negócio. Mas se uma equipe decidir que vai ser mais prático assim e teve experiencia de sucesso, então que se respeite.
Uma coisa vocês tem razao, Hibernate (do Java) parou no tempo, sentou no sucesso, tá na hora de acordar e ter mapeamento programático, pois no NHibernate do .NET é tudo perfeito nesse aspecto, por isso eu gosto tanto e seria muito bom ter isso no Java também.
Por fim, seja lá qual for opção, vai poder usar SQL do jeito que quiser mesmo, e o resultado será automaticamente populado em uma lista de uma classe, ou um valor direto no caso de query scalar.[/quote]
É esse “automaticamente” que as vezes assusta… Talvez essa (na minha opinião) seja a principal desvantagem do Hibernate… Querer fazer as coisas por conta, lazy loadings, transações, a própria população das entidades, etc…
Sua argumentação é válida… Nunca vi esse NHibernate pois não trabalho com .NET, mas pelo que vc disse já me parece um avanço…
Entendo, mas se você ver que a coisa sempre vai funcionar então se torna confiável, e se quiser pode tranquilamente popular a lista de objetos na mão também para esses casos de SQL, não existem leis dentro do framework. Importante é usar o que for de consenso da equipe para sucesso da vida do projeto e conforto dos seres humanos envolvidos. No seu caso é o MentaBean, que realmente admiro o mapeamento programático.
Entendo, mas se você ver que a coisa sempre vai funcionar então se torna confiável, e se quiser pode tranquilamente popular a lista de objetos na mão também para esses casos de SQL, não existem leis dentro do framework. Importante é usar o que for de consenso da equipe para sucesso da vida do projeto e conforto dos seres humanos envolvidos. No seu caso é o MentaBean, que realmente admiro o mapeamento programático.[/quote]
Talvez nem seja tanto pelo “tornar-se confiável”, mas sim pela falta de controle que vc tem sobre o framework… Quem disse que deixar tudo por conta do Hibernate é algo positivo?
Acho que qualquer iniciativa que venha acrescentar possibilidades a nossa área (desenvolvimento) é válida. A adoção ou não vai depender de cada um.
Acho também que nenhum framework foi criado com a finalidade de abstrair o conhecimento do desenvolvedor e sim de facilitar as coisas. Usar um framework de ORM sem ter o mínimo conhecimento de banco de dados é loucura … isso com qualquer framework, seja hibernate/jpa ou outro qualquer.
Não duvidei do suporte à diferentes dialetos, na verdade acho isso algo bem interessante. O que quis levantar foi: SOMENTE com JPA que terei suporte à outros bancos? E a resposta é: Não.
Este ganho na produtividade existe em outros frameworks também, e nem por isso precisam fazer “mágica” pra isso. O exemplo que mais posso argumentar é o caso do MentaBean… Você monta a sql como quiser e nem por isso precisa percorrer o ResultSet manualmente para formar a lista de retorno, não importa o quão complexa seja a query.
O xml não fica “preso ao fonte”. Como a configuração não é programática, a cada alteração na sua camada de negócios (inclusão, alteração ou remoção de alguma propriedade), você deve catar a respectiva configuração no xml e alterar lá também. Ou seja, vc perde uma grande vantagem: refatoração.
[/quote]
Concordo. [=
Sim, mas aí você perde portabilidade. Em sistemas isso pode ser vantagem, em outros desvantagem.
De qualquer modo você vai precisar fazer algum arquivo que relacione o nome de uma tabela a um atributo. xml, properties, anotação, runtime ou seja lá o que for.
Eu ainda não vejo no mercado um ORM que que seja bom quanto ao Hibernate a ponto de produção + portabilidade + material no mercado + profissionais no mercado.
O Spring tem suas soluções e ainda estou para estudá-las, então me desculpe se estou ofendendo algum mano spring aí. :lol: :lol: :lol:
