Hibernate, o assunto era Reinventar a roda, mas isso não tem mais importância

Abstrair não é re-inventar a roda. Veja o exemplo abaixo que eu descrevo em http://book.mentaframework.org/posts/list/5.page

Contando caracteres com Ruby

file = File.open(ARGV[0])

count = 0;

file.each { |line| count += line.chomp.length }

puts "Number of chars: #{count}"

Contando caracteres com Java

import java.io.*;

public class CountChars {

    public static void main(String[] args) {
 
        try {       
            
            FileInputStream fos = new FileInputStream(args[0]);
            
            BufferedReader in = new BufferedReader(new InputStreamReader(fos));
            
            String line;
            
            int count = 0;
            
            while((line = in.readLine()) != null) {
                
                count += line.length();
                
            }
            
            System.out.println("Number of chars: " + count);
            
        } catch(IOException e) {
            
            System.out.println("An error happened: " + e.getMessage());
            
        }
    }
}

Se contar caracteres for uma operação que vc executa sempre e a cada novo projeto, então merece uma bela abstração:

import java.io.*;

public class CountChars {

    public static void main(String[] args) {
 
        int count = FileUtils.countChars(args[0]);
        
        System.out.println("Number of chars: " + count);
 
    }
}

Isso se chama abstrair para facilitar a vida. Se vc quiser fazer tudo na unha para não ter que aprender o framework e o seu FileUtils.count, então tudo bem, mas aí sim vc vai perder tempo reinventando a roda.

Outro exemplo gritante. Todo projeto precisa de um pool de conexões. Então veja como vc configura um pool de conexões no tomcat:

<Context path="/dbcp" docBase="dbcp" debug="5"
reloadable="true" crossContext="true">

<Resource name="jdbc/TestDB" auth="Container"
   type="javax.sql.DataSource" removeAbandoned="true"
   removeAbandonedTimeout="30" maxActive="100"
   maxIdle="30" maxWait="10000" username="kunal"
   password="java_facier"
   driverClassName="com.mysql.jdbc.Driver"
   url="jdbc:mysql://localhost/dbcptest"/>

</Context>

<listener>
        <listener-class> com.onjava.dbcp.DBCPoolingListener</listener-class>
</listener>

<!-- This component has a dependency on an external resource-->
 <resource-ref>
      <description> DB Connection Pooling</description>
      <res-ref-name> jdbc/TestDB</res-ref-name>
      <res-type> javax.sql.DataSource</res-type>
      <res-auth> Container</res-auth>
  </resource-ref>

<servlet>
        <servlet-name> EnrolledStudents</servlet-name>
        <servlet-class> com.onjava.dbcp.CourseEnrollmentServlet</servlet-class>
        <load-on-startup> 1</load-on-startup>
</servlet>

<servlet-mapping>
        <servlet-name> EnrolledStudents</servlet-name>
        <url-pattern> /enrollment.do</url-pattern>
</servlet-mapping>

public class DBCPoolingListener implements
ServletContextListener{
 public void contextInitialized
  (ServletContextEvent sce){

  try {
    // Obtain our environment naming context
    Context envCtx = (Context) new InitialContext().
    lookup("java:comp/env");

    // Look up our data source
    DataSource  ds = (DataSource) envCtx.lookup
       ("jdbc/TestDB");

    sce.getServletContext().setAttribute
      ("DBCPool", ds);
   } catch(NamingException e){ e.printStackTrace();
  }
 }
 public void contextDestroyed(ServletContextEvent
 sce){
 }
}

public void init() throws ServletException {
    try {
 //Create a datasource for pooled connections.
 datasource = (DataSource) getServletContext().
 getAttribute("DBCPool");

  //Register the driver for non-pooled connections.
  Class.forName("com.mysql.jdbc.Driver").
      newInstance();
    }
private synchronized Connection getConnection
    (boolean pooledConnection)
    throws SQLException {
  if (pooledConnection) {
     pooledCount++;

    // Allocate and use a connection from the pool
    return datasource.getConnection();
  }
  else {

    nonPooledCount++;
    Connection con = DriverManager.getConnection(
      "jdbc:mysql://localhost/dbcptest","kunal",
      "java_facier");
    return con;   //return a newly created object
    }
  } catch (Exception e) {
      throw new ServletException(e.getMessage());
    }
  }

Fonte: http://www.onjava.com/pub/a/onjava/2006/04/19/database-connection-pooling-with-tomcat.html

Isso é sem dúvida uma aberração. Uma Rube Goldberg machine.

Veja como vc faz um pool de conexões com o Mentawai:

public class ApplicationManager extends org.mentawai.core.ApplicationManager {
    
    private ConnectionHandler connHandler = null;
    
    public void init(Context application) {
    
        // assuming you have a mysql database with a "lohis" database with username "lohis" and password "lohis"
        this.connHandler = new DBCPConnectionHandler("com.mysql.jdbc.Driver", 
                                                     "jdbc:mysql://localhost/lohis?autoReconnect=true", 
                                                     "lohis", 
                                                     "lohis");

        filter(new ConnectionFilter("conn", connHandler));
    }
}       

public String execute() throws Exception {
        
    Connection conn = (Connection) input.getValue("conn");

    // do what you have to do with the connection... no need to return the connection to pool...

    return SUCCESS;
}

Então. Vc acha que isso é reinventar a roda?

Não Saoj, eu sou a favor de tudo isso, oque eu sou contra é gerar trezentas configurações para tentar abstrair uma coisa e torná-la mais complexa, um exemplo é o Hibernate ou o Spring, diga-se de passagem, são excelentes e fazem bem oque propõem, mas depende de muita configuração e não seguem nenhuma especificação entende?

Assim como no mtw, o guice (juice) do google faz praticamente o mesmo que o spring faz (estou falando apenas de DI) e é extremamente mais simples…

Concordo plenamente com vc. Ninguém duvida do poder e da qualidade desses frameworks, mas vc precisa saber tantos detalhes na hora de usar e configurar que intimida um pouco.

O que mais tem por aí é gente usando Spring para fazer uma simples injection. Por isso que surgiu o Guice (e agora o Miocc). Repare que o Guice utiliza configuração programática para configurar os componentes. Está bastante claro pra mim que [color=blue]se a configuração virou uma complexidade a mais, ela tem que ser feita programaticamente para poder ser abstraída e simplificada[/color]. E algumas pessoas continuam pensando erradamente que as configurações podem ser resolvidas com conventions. Conventions amenizam o problema mas não resolvem porque para certas coisas não há como escapar da configuração. Dá para escapar da configuração do pool de conexões ??? Dá para escapar da configuração de IoC e DI ??? Dá para escapar da configuração de ORM ??? E não estou contando os casos que vc quer escapar da convenção, como por exemplo na camada view. Ficar limitado o tempo todo a /User.add.mtw vai para /User/add.jsp é extremamente impraticável num projeto sério.

Eu até hoje uso JDBC com uma ferramenta simples que abstrai as queries mais simples de CRUD pra mim. Um dia irei usar/aprender Hibernate, mas infelizmente pra mim esse momento ainda não chegou, por falta de necessidade e vontade mesmo.

Exemplo extraído do site do Hibernate.

private List listEvents() { Session session = HibernateUtil.getSessionFactory().getCurrentSession(); session.beginTransaction(); List result = session.createQuery("from Event").list(); session.getTransaction().commit(); return result; }

Exemplo de como ficaria a mesma coisa em JDBC puro.

private List listEvents() { Connection con = getConnection(); Statement stmt = con.createStatement(); ResultSet rs = s.executeQuery("select * from event"); try { return getAsList(rs); } finally { rs.close(); stmt.close(); } }

Além é claro de não ter que aprender uma HQL por exemplo, é muito mais legível. Oque precisa de abstração aqui?? Na minha opinoão o método getAsList que pode usar um mapper para fazer o bind, mas só isso! Não precisa reescrever o mundo inteiro e ainda deixar a mesma coisa.

Tá tá tá, o Hibernate não é só isso, mas como dizia meu pai, um erro não justifica o outro.

Saoj sou completamente a favor da opinião de as configurações devem ser programáticas, mas tambem não sou contra os xmls, sou contra o mal uso deles.

é muito mais fácil vc fazer um

bind(MyObj.class).in(Scope.singleton)

do quê:

mas será que ninguem tá vendo isso??

Quando vc vai a um restaurante e já na entrada a comida está estragada, então eu prefiro nem ficar para o prato principal. O “Getting Started” do Hibernate, isso mesmo, o HelloHibernate, utiliza transação para um select. Veja o exemplo que vc postou:

private List listEvents() {
    Session session = HibernateUtil.getSessionFactory().getCurrentSession();
    session.beginTransaction();
    List result = session.createQuery("from Event").list();
    session.getTransaction().commit();
    return result;
}

Não faz qualquer sentido ter um commit para um select, mas se a própria documentação do Hibernate incentiva isso então temos um problema.

E vc não colocou a parte mais importante que é a configuração disso tudo via annotations ou xml. (Ok, ele suporta configuração programática, mas ninguém usa, não é recomendado pelos autores e não há documentação clara, então é próximo de inexistente)

Algumas pessoas vão falar que somos malucos, porque elas dominam o Hibernate e sabem que ele pode fazer coisas maravilhosas, desde do mais simples até o mais complexo.

Entretanto para carregar uma lista de beans, eu vou continuar fazendo assim:

List<Carro> carros = session.loadList(Carro.class);

Para carregar uma lista de todos os carros do RJ:

Carro carro = new Carro();

carro.setEstado("RJ");

List<Carro> carros = session.loadList(carro);

Para fazer um insert:

Carro carro = new Carro();
carro.setEstado("RJ");
// outros setters...

session.insert(carro);

E para configurar, eu vou continuar fazendo assim:

// Mentabean configuration
BeanConfig carro = bean(Carro.class, "Carros")
                .pk("id", DBTypes.AUTOINCREMENT)
                .field("name", DBTypes.STRING)
                .field("estado", DBTypes.STRING)
                .field("year", DBTypes.DATE)
                .field("motorId", "motor_id", DBTypes.INTEGER);

E para as queries mais complexas eu faço um SQL na mão mesmo.

Bem no meu ver o hibernate e um gigantesco framework com diversas configurações… mais ai vai a questão… se vc quiser usar o hibernate precisa usar todo ele??? para fazer insert na mão com jdbc e um saco… imagine um bean com 100 atributos que vc tenque fazer um insert desse bean na hora de gravar em 5 tabelas… pra fazer isto e extremamente desgastante e trabalhozo… usando o hibernate ai vc ganha bem mais vantagem pois pode usar um dos diversos scripts de mapeamento porai pra ele fazer o mapeamento do bean com as tabelas e depois e so chamar o metodo de insert do hibernate… agora não significa que pq vc use o hibernate vc tera que usar so o hibernate em todo o projeto… se vc achar mais simples fazer consultas por jdbc do que com criteria ou hql vc pode usar perfeitamente jdbc para isto… não se restringe apenas ao hibernate… varios frameworks tem milhares de configurações mas em grande parte vc precisara usar apenas 20% delas…

Veja o meu exemplo no post anterior. Usar JDBC totalmente puro não dá. Vai ser trabalhoso. O negócio é usar JDBC + uma ferramenta que te ajuda na construção das queries e que faça as queries básicas de CRUD pra vc. Acho que o iBatis vai mais por esse lado. O Mentabean , que já vem com o Mentawai, foi feito exatamente para esse propósito. Mas ninguém aqui está falando que quem usa o Hibernate está errado.

saoj:

Quando vc entra na casa de alguém pela primeira vez e encontra uma imensa bosta de cachorro no meio da sala, vc se assusta um pouco. O “Getting Started” do Hibernate, isso mesmo, o HelloHibernate, utiliza transação para um select. Veja o exemplo que vc postou:

private List listEvents() {
    Session session = HibernateUtil.getSessionFactory().getCurrentSession();
    session.beginTransaction();
    List result = session.createQuery("from Event").list();
    session.getTransaction().commit();
    return result;
}

Não faz qualquer sentido ter um commit para um select, mas se a própria documentação do Hibernate incentiva isso então temos um problema.

-E-X-A-T-A-M-E-N-T-E-

Imagino pq a configuração programática é desaconselhada.

Mas era exatamente esse o ponto que eu queria que essa discussão chegasse… NÃO HÁ ABSTRAÇÃO DE COMPLEXIDADE NISSO!!

Reinventar a roda é uma expressão preconceituosa. Se o ser humano não tivesse reinventado a roda os automóveis não teriam pneus e as rodas de automóvel , trem e avião seria iguais e rodas dentadas não existiriam.

Reinventar a roda é importante se for necessário. Mas só se for necessário.

O uso de vários frameworks sem integração/orquestração pode gerar demasiados artefactos e tornar o sistema complexo de manter (não, obviamente, para quem o construiu). Por isso que é bom usar padrões de mercado ( e me refiro a padrões como EJB e não a “frameworks que o povo usa” )

A configuração por codigo é extreamamente importante porque é a forma que o framework fornece para que seja integrado num framework maior. E tem outras vantagens como a possibilidade de escreve essa configuração em alguma linguagem de script de forma que possa funcionar como um properties inteligente.
A configuração com xml ou anotações deve ser apenas um simplificador ou um extensor. Por exemplo, um framework de desenho de telas pode se aproveitar de xml para gerar as telas com ferramentas.
A configuração por convenção é apenas dizer que existe um default para cada opção e que esse default deve ser escolhido conforme o uso mais comum do framework em causa. ( por exemplo, a configuração por convenção de um ORM deveria simplesmente não precisar de nenhuma configuração , anotação ou xml: simplesmente assume que os campos tem os nomes das colunas e classes das tabelas e converte os tipos primitivos sozinho)

Num framework a capacidade dele ser simples para quem não o entende, extensivel para casos particulares e configurável para casos raros é o que o torna uma boa ferramenta. Mas existem casos em que as ferramentas falham, e isso é normal (ler 50000 registros com hibernate…). Por isso que o principio de separação de responsabilidade deve ser seguido À risca e todo framework deve ser encapsulado por um codigo de aplicação.(padrão Façade ou Service)
Desta forma quando o framework não atender ou tiver que ser substituido a aplicação não sofre.

Acredito que o ponto em achar que Hibernate é complexo é diretamente relacionado à não entender o problema que ele soluciona. ORM não é simples e tentar fazer com JDBC caseiro é alo que não funciona. Implemente lazy loading (algo extremamente básico em qualquer sistema OO) no seu exemplo e você vai entender melhor o problema antes de criticar a solução.

Em primeiro lugar, ninguem aqui falou que é contra o hibernate, apenas estamos questinando a forma que ele é configurado e o aumento da complexidade que ele gera.

Segundo, ORM não é simples e muito menos o hibernate.

E por fim… ninguem tá questionando a funcionalidade do hibernate, ele tem lazy load ohhh o ibatis tambem tem, ele tem cache ohhh o ibatis tambem tem e mantem a simplicidade. O problema é que não se justifica criar uma nova linguagem HQL para trabalhar com os dados, a menos que queira deixar seu sistema mais lento além do mais não se troca de banco de dados como se troca de roupa neh??

JDBC não funciona? O Hibernate roda em cima doque?? Do Windows??? Na minha opinião se as pessoas se preocupassem em aprender mais as coisas veriam que JDBC não é tão complexo assim e utilizariam-no mais.

A maioria das pessoas que usam hibernate é que não entende o problema que ele soluciona, simplesmente começam usar o hibernate sem ter conhecimento do JDBC oq temos que convir que é errado e dá na mesma de começar usar struts sem saber oq é servlet.

Mais uma vez reitero que não estamos questionando o hibernate, e sequer a sua funcionalidade já enfatizada neste tópico, mas sim a relação framework vs. api java, quais os ganho em relação à complexidade nos usos de um ou de outro.

Coisas do tipo, eu preciso comitar minhas queries, tá mas com jdbc eu não precisava…

Entendeu??

Uma coisa é consequência da outra.

volnei:

E por fim… ninguem tá questionando a funcionalidade do hibernate, ele tem lazy load ohhh o ibatis tambem tem, ele tem cache ohhh o ibatis tambem tem e mantem a simplicidade.

IBatis possui uma filosofia de ORM comletamente diferente, baseada em DAOs. O Hibernate não diz como seus dados serão acessados. IBatis costuma ser uma boa escolha quando sua base de dadosnão é consequência do seu modelo OO.

Você está partindo de uma premissa errada, como eu já havia alertado. HQL não é para tratar dados, é para tratar objetos. Objetos e relacionamentos são coisas muito diferentes e SQL não serve nos dois meios. Faça uma consulta polimórfica com SQL.

Quem falou que JDBC não funciona?

Ok. Faça uma consulta polimórfica com SQL em todas as estratégias de persistência de herança comuns e implemente lazy loading nela.

volnei:

Coisas do tipo, eu preciso comitar minhas queries, tá mas com jdbc eu não precisava…

Entendeu??

Pelo que entendi seu programa não é transacional…

Como o autor do post falou, ninguém aqui está questionando o Hibernate, só que existe outras alternativas, como sempre dependendo do caso.

Minha opinião é que lazy loading só passa a ser essencial quando temos grafos de objetos muito grande (acima de 3 níveis de composição).

Hibernate tem outras coisas mais complexas como remoção em cascata, suporte a herança, locks e cache.

Se eu carrego um carro, que possui um monte de partes, que por sua vez possuem um monte de peças (composição em tres níveis), usando JDBC, eu terei que fazer esses tres carregamentos distintos na mão quando eu achar que eles são necessários. O Hibernate faz isso automaticamente quando o getter (getPartes, getPecas) são invocados.

Há controversias até que ponto lazy loading automático é bom ou ruim. Minha opinião é que vc (desenvolvedor) é que deve saber quando e onde as dependencias serão necessárias e carregá-las na mão, mas concordo que se o grafo é gigantesco isso pode se tornar trabalhoso.

Nada te impede também de programar na mão lazy loading em suas entidades, ou seja, quando o cara chamar o getPecas() vc checa se já foi carregado do banco, se tiver sido retorna, se não tiver sido então vai carregar. Vc não precisa obrigatoriamente de Hibernate para fazer isso.

Há uma discussão extensa sobre lazy loading aqui: http://www.guj.com.br/posts/list/57590.java

Outras:

Lazy Loading: Good or Bad: http://www.matshelander.com/wordpress/?p=45

Lazy Loading: The good, The bad and the Evil: http://weblogs.asp.net/fbouma/archive/2007/04/16/more-on-lazy-loading-vs-pre-loading-in-o-r-mapping-scenarios.aspx

O tópico não é sobre Lazy Loading ou Hibernate ou ORM, mas sim sobre abstração x reinventar a roda.

pcalcado:

volnei:

Em primeiro lugar, ninguem aqui falou que é contra o hibernate, apenas estamos questinando a forma que ele é configurado e o aumento da complexidade que ele gera.

Uma coisa é consequência da outra.

pcalcado:

A filosofia é diferente mas o objetivo é o mesmo.

No fim tudo vira SQL se vc consegue fazer com HQL vc consegue fazer com SQL. A abstração da complexidade é que não fica muito clara quando se fala em criar uma linguagem intermediária.

Bom mas uma vez, consultas polimóficas é uma idéia de design no mínimo ridicula, lazy loading se faz utilizando uma biblioteca qualquer feita pra isso, até mesmo a que o hibernate usa.

pcalcado:

Que programa? Mas uma vez você está se equivocando, eu não to falando que tenho a solução do mundo, estou apenas discutindo oque existe.

volnei:

Então???

Então que ou você sugere algo que traga os mesmos benefícios e seja mais simples ou essa crítica não faz sentido.

Java, C++e C# fazem a mesma coisa. São iguais?

Eu consigo fazer uma aplicação web em assembly. No final tudo vira código de máquina mesmo, porque eu usaria Java?

Eu Não falei que JDBC não funciona, eu falei que fazer lazy loading com JDBC caseiro não funciona.

‘biblioteca que o hibernate usa’? O hibernate é uma implementação de ORM, ele é a biblioteca de lazy loading que usa. Novamente: entenda o problema antes de criticar a solução.

Polimorfismo é uma idéia ridícula então? Acho que é melhor você ler alguns textos sobre orientação a objetos. Você pode até não gostar de usar objetos e suas características (como polimorfismo) mas se o fizer porque está usando java em primeiro lugar?

volnei:

Que programa? Mas uma vez você está se equivocando, eu não to falando que tenho a solução do mundo, estou apenas discutindo oque existe.

E ‘o que existe’? Transações? Se você acha que transações são ruins basta abstrair seu uso. Existem dezenas de formas de fazer isso, caseiras ou não. O idioma do-commit/rollback é padrão para qualquer interação entre dois sistemas, isso não tem nada inventado pelo Hibernate.

volnei:

Esse termo tão utilizado aqui e nos diversos fóruns e blogs do mundo não tá um pouco ultrapassado? Estou iniciando uma discussão…

:XD:

T+

Ao meu ver o hibernate nao e um framework de abstração de complexidade e sim de abstração de trabalho…

Boa Proteu :idea:

luistiagos:

Ao meu ver o hibernate nao e um framework de abstração de complexidade e sim de abstração de trabalho…

OK, mas deixarei claro pela ultima vez, NÃO ESTOU FALANDO DO HIBERNATE, estou falando de abstração de complexidade vs. reiventar a roda… será que é tão dificil se manter no assunto??

Talvez devessemos nos tratar como usuários do nosso próprio código/framework
e fazer com que eles sejam mais amigáveis.

Ok, o tópico fala sobre abstração de complexidade e não de quantidade de benefícios ou coisa parecida, agora se quer algo melhor que o hibernate aí vc abre um tópico só seu e aposto que vai ter gente que prefere JDBC à Hibernate. Nem tudo que te agrada agrada aos outros.

Não sabia que fazem a mesma coisa, aliás sequer citei isso quando me referi ao objetivo. Qual o principal objetivo do Java? Bem diferente do C++ e mais ainda do C# neh?

Tambem consegue fazer uma aplicação web usando todos os frameworks quanto possivel, mas isso seria tão estúpido quanto. Tambem consegue matar uma mosta com uma metralhadora mas não precisa de uma não é??

Nossa isso é totalmente relativo, não tem como falar que não funciona… à não ser que exista algum framework pronto chamado “caseiro” eu acho que se vc implementar bem vai funcionar.

Sério, e a CGLIB? É apenas mais uma das dezenas de apis que o hibernante usa?

O ow… mais uma vez vc distorceu minha resposta, em nenhum momento eu disse que polimorfismo é ridiculo, apenas falei sobre as queries polimórficas. Então oque você falou não faz o menor sentido!

Você disse que meu programa não era transacional, apenas gostaria de saber que sistema você está falando. Quanto ao commit e rollback o hibernate não inventou nada mesmo, apenas que você tinha que commitar consultas sql. rsrs

Pela última vez não estou falando de hibernate tá, sugiro que você leia o post inicial que apenas sita um exemplo do hibernate além do mais tudo que é feito com ele é possivel fazer com java -mesmo que vc não acredite- caso contrário ele teria sido desenvolvido em outra linguagem.

o assunto em questão continua sendo ABSTRAÇÃO DE COMPLEXIDADE VS. REINVENTAR A RODA

fabioissamu:

Talvez devessemos nos tratar como usuários do nosso próprio código/framework
e fazer com que eles sejam mais amigáveis.

Esse era o tipo de resposta que eu queria nesse post! Mas o pessoal gosta de hibernate.

Falo exatamente nisso, coisas amigáveis!!

“Reinventar a roda” é uma expressão que pode significar qualquer coisa de ruim, onde não se precisa pensar muito. É a mesma coisa que os esquerdistas radicais fazem ao falar a palavra “privatização”: não se pensa muito, apenas serve pra dizer que é ruim.

Abstrair criando um novo idioma por cima (como o Hibernate, que faz com que tratamos os dados relacionais como se fossem orientados a objetos) não é errado. O causa do problema do “configuration hell” não é a abstração em si, mas como foi feita essa abstração.

Não vejo em Java nenhum tipo tratamento de configuração muito bom, nem xml, anotations ou no próprio código (apesar de, particularmente, dar preferência a anotations sobre os demais). O que considero muito bom mesmo é o que o ActiveRecord faz usando o Ruby. Aquele “validate_presence_of”, por exemplo, parece mágica, mas é só um método de classe de ActiveRecord::Base, chamado apenas uma vez e que irá alterar o comportamento da classe, e ainda por cima, sem necessidade de container. Mas é pena que é um comportamento difícil de se reproduzir no Java, pelo menos não tão facilmente.

Justifica sim. A HQL é uma forma de abstrair o SQL nativo. Isso é importante num mecanismo de abstração como o Hibernate que tem que produzir SQL ligeiramente diferente conforme o banco de dados.

Por outro lado o HQL é uma implementação do padrão Intrepreter. Este padrão permite que seja incluidas funcionalidades de forma desacoplada do SQL subjacente. Em particular trabalhar com classe e objetos e não com tabelas e linhas.

O único problema do HQL é que não é padrão (no sentido de que é suportando por um produto e não como o SQL que é por uma especificação). Mas isto é natural. A necessidade do HQL existir é maior ( porque advém directamente do objetivo do Hibernate) que a necessidade de ser padronizado ( coisa que o SQL tb não é 100%)

saoj:

Quando vc vai a um restaurante e já na entrada a comida está estragada, então eu prefiro nem ficar para o prato principal. O “Getting Started” do Hibernate, isso mesmo, o HelloHibernate, utiliza transação para um select. Veja o exemplo que vc postou:

private List listEvents() {
    Session session = HibernateUtil.getSessionFactory().getCurrentSession();
    session.beginTransaction();
    List result = session.createQuery("from Event").list();
    session.getTransaction().commit();
    return result;
}

Não faz qualquer sentido ter um commit para um select, mas se a própria documentação do Hibernate incentiva isso então temos um problema.

Serio Sergio, voce precisa mesmo pesquisar mais antes de falar essas coisas. Em especial do hibernate, que uma enorme quantidade de casos muita gente corrigiu coisas que voce falava que nao dava pra fazer, ou que seria complicado.

Voce acha mesmo que nao ha uma razao pela qual um programador super reconhecido fez uma transacao em volta de um select? Se acha que nao, pesquise. quer ja mastigado? va ao google e procure por “selects query inside function must read commited data”. Ha sim uma diferenca, e muito significativa dependendo do seu commit option. Alias, li por aqui que voce ja trabalhou em sistemas grandes com muita concorrencia, e é nesses casos que costumam aparecer dirty reads, phantom reads, etc… Ja que quem esta certo nesse caso é o hibernate, a comida estragada nao estaria no mentabeans, que esta ensinando select sem transacao?

Sua declaracao é: “se a documentacao do hibernate mostra um exemplo com boas praticas que eu nao entendi , logo temos um problema”. Que problema? Que as pessoas vao ter de entender o porque daquilo? Explique o problema, nao sei do que voce esta falando.

Outra afirmacaosu , falando sobre a configuracao programatica ser praticamente inexistente. Se ela existe, como ela é praticamente inexistente? Alias, antigamente voce declarava que nao existia, sem saber, e nem mesmo procurar!

Fico chateado em ouvir declaracoes como essa a respeite de um framework como o hibernate, que sem duvida é hoje em dia o framework de mais sucesso do mundo, em termos de qualidade, confiabilidade, performance, documentacao, etc. Se o hibernate é ruim, o que é bom?

Paulo Silveira:

saoj:

Não faz qualquer sentido ter um commit para um select, mas se a própria documentação do Hibernate incentiva isso então temos um problema.

Serio Sergio, voce precisa mesmo pesquisar mais antes de falar essas coisas. Em especial do hibernate, que uma enorme quantidade de casos muita gente corrigiu coisas que voce falava que nao dava pra fazer, ou que seria complicado.

Voce acha mesmo que nao ha uma razao pela qual um programador super reconhecido fez uma transacao em volta de um select? Se acha que nao, pesquise. quer ja mastigado? va ao google e procure por "selects query inside function must read commited data". Ha sim uma diferenca, e muito significativa dependendo do seu commit option. Alias, li por aqui que voce ja trabalhou em sistemas grandes com muita concorrencia, e é nesses casos que costumam aparecer dirty reads, phantom reads, etc…

Sua declaracao é: "se a documentacao do hibernate mostra um exemplo com boas praticas que eu nao entendi , logo temos um problema". Que problema? Que as pessoas vao ter de entender o porque daquilo? Explique o problema, nao sei do que voce esta falando.

Outra afirmacaosu , falando sobre a configuracao programatica ser praticamente inexistente. Se ela existe, como ela é praticamente inexistente? Alias, antigamente voce declarava que nao existia, sem saber, e nem mesmo procurar!

Fico chateado em ouvir declaracoes como essa a respeite de um framework como o hibernate, que sem duvida é hoje em dia o framework de mais sucesso do mundo, em termos de qualidade, confiabilidade, performance, documentacao, etc. Se o hibernate é ruim, o que é bom?

Paulo, o próprio sergio falou aqui que quem usa hibernate não está errado, não é uma crítica ao hibernate e sinceramente se eu falei alguma besteira aqui agradeço se me corrigirem tambem pois não sei tudo de hibernate.

A questão que eu estou falando é com relação ao Reinventar a roda, ou seja se um cara pegasse todos os códigos do hibernate os estudasse e fosse desenvolver um framework o "Cópia de hibernate(1)" ele o faria diferente, talvez melhor, talvez pior, mas não estaria inventando a roda, estaria criando uma nova opção, vocês que usam hibernate devem conhecer algum defeito nele e é disso que eu estou falando, talvez fosse inviável fazer aquela alteração que vc tanto queria mas desenvolver outro com essa alteração não seria inviável pois o melhoraria muito.

E isso não é só com hibernate, isso é com a maioria dos frameworks, o Struts por exemplo, entenda, EXEMPLO, poderia ter desenvolvido seu próprio controler ao invés de usar o xwork, isso poderia resolver outros problemas como o fato de eu ter que ter um xwork-conversion.xml dentro do meu projeto em struts, não estou falando em não usar apis, estou falando em não ficar amontuando framework em cima de framework e gerando coisas escabrosas… Daqui a pouco vai ter gente desenvolvendo frameworks em cima do struts para abstrair a complexidade do mesmo aí teremos xwork > struts > Novo Framework e vai saber até aonde iria, ou até mesmo do hibernate.

[]'s

Oi Volnei

Respondendo suas perguntas

• O Hibernate segue a JPA se voce quiser usa-lo dessa maneira.
• O Rod Johnson nao esta participando a toa como um dos lideres da especificacao do Java EE 6.0. Spring vai acabar implementando alguma especificacao, essa é um aposta minha pessoal.
• Quem usa Oracle e sabe que nao vai mudar de bancos usaria o Hibernate para gerenciar o estado dos objetos persistentes, e nao apenas esconder as queries sql. Gerenciar estado é saber a hora que o objeto foi modificado, a hora de fazer o update, a hora de verificar mudanca concorrente, a hora de buscar mais dados no banco, etc. Entao voce deixa o gerenciamento de estado na mao do hibernate, que é algo que da muito trabalho quando temos envolvidas muitas entidades.

Paulo Silveira:

Respondendo suas perguntas

• O Hibernate segue a JPA se voce quiser usa-lo dessa maneira.
• O Rod johnson nao esta participando a toa como um dos lideres da spec do Java EE 6.0. Spring vai acabar implementando alguma spec, minha aposta pessoal.
• QUem usa Oracle e sabe que nao vai mudar de bancos usaria o Hibernate para gerenciar o estado dos objetos persistentes, e nao apenas esconder as queries sql. Gerenciar estado é saber a hora que o objeto foi modificado, a hora de fazer o update, a hora de verificar mudanca concorrente, a hora de buscar mais dados no banco, etc. Entao voce deixa o gerenciamento de estado na mao do hibernate, que é algo que da muito trabalho quando temos envolvidas muitas entidades.

Certo Paulo, mas não justifica ao meu ver, por exemplo usar o hibernate num projeto com 10 entidades. Mas oque eu estou querendo dizer é oque está no meu ultimo post acima deste…

Serio Paulo. Não precisa ficar nervoso. Não conconrda com os meus argumentos, então basta colocar os seus. Essa revolta toda é desnecessária e não ajuda em nada ao debate. Toda vez que eu falar uma coisa que vc considera errado, fique a vontade para contra argumentar de maneira educada. Quem ganha com isso é o forum.

Minha especialidade não é banco de dados, nem ORM. O tópico também não é sobre isso, como o autor já enfatizou bastante. Mas gostaria de pedir a sua autorização para tentar dar minha opinião, posso? Se eu falar uma coisa errada ou que vc não concorde me desculpe ok?

Vc está falando de temas avançados: Dirty read e phanton read. Eu prefiro pensar apenas como o Oracle e outros bancos de dados de primeira linha pensam: “Leituras nunca são bloqueadas e nunca bloqueiam ninguém. Escritas bloqueiam apenas outras escritas.” Eu realmente acho um disperdício de recursos e simplicidade querer colocar uma transação ao redor de uma leitura por default pra tudo porque vc está com medo do isolation level do seu banco. Já vi muitas pessoas usando o hibernate sem transaction para a select e o sistema deles funciona muito bem.

Calma, Paulo. Não trabalho com concorrencia. (Onde vc leu isso?) Trabalho com NIO. Tudo single threaded. Já trabalhei com concorrencia mas a nível de thread e não a nível de banco de dados. Não sou DBA Oracle.

E sobre o select, então quando vc trabalha com JDBC vc abre uma transação antes de cada select que vc dá? Eu realmente acredito que o default deva ser “não usar transações para selects”. Agora se vc pensa diferente porque vc está com medo dos phanton reads, me desculpe.

Vou repetir minhas palavras aqui: " E vc não colocou a parte mais importante que é a configuração disso tudo via annotations ou xml. (Ok, ele suporta configuração programática, mas ninguém usa, não é recomendado pelos autores e não há documentação clara, então é próximo de inexistente)"

Vc está vendo o que quer ver ou lendo o que quer ler. Eu nenhum momento eu falei que era ruim, muito pelo contrário. A minha crítica foi que para um grande número de situações mais simples ele pode se tornar uma bazooka para matar uma mosca.

Se vc ficou chateado, me desculpe. Vou ajudar o autor do tópico: ESSE TÓPICO NÃO É SOBRE O DOGMA HIBERNATE! Assim realmente fica difícil qualquer discussão mais interessante nesse forum…

Será que agora alguem vai responder?? Parece que só se fala em Hibernate aqui.

To começando achar que o java roda em cima do hibernate…

Eu acho que em sistemas bem simples o hibernate ajuda pra caramba. As vezes não preciso nem me preoculpar com coisas mais cascudas. Simplesmente uso @Entity as vezes @Transient e fica tudo limpinho e bem facil. Para CRUDS então vira algo trivial.

Sinceramente não to visualizando o que tem de complexo nisto.

emerleite:

Eu acho que em sistemas bem simples o hibernate ajuda pra caramba. As vezes não preciso nem me preoculpar com coisas mais cascudas. Simplesmente uso @Entity as vezes @Transient e fica tudo limpinho e bem facil. Para CRUDS então vira algo trivial.

Sinceramente não to visualizando o que tem de complexo nisto.

Ok, só que como citado XXX vezes esse tópico [size=24]NÃO É SOBRE HIBERNATE![/size]

O problema é que você começou esse tópico criticando o Hibernate. Aí o saoj continuou, dando exemplo do MentaBean, e você concordou, aí apareceu a galera que conhece e usa o Hibernate pra dar as opiniões, você ficou irritado e deu no que deu.
Ao meu ver, você tomou a opinião do pcalcado como pessoal… Ele estava só querendo continuar a discussão, contraargumentando o que você começou. O saoj também se irritou com o que o Paulo disse, mas nem vi essas ofensas todas.
Por favor, não estou querendo continuar o flame. Não quis ofender ninguém com esse post.

Primeiramente que está irritado aqui acho que não sou eu… mas se as pessoas tivessem um pingo de noção não colocariam mensagens que não colaboram com o tema proposto, a exemplo da sua!

Cadê a critica??

Quem se atreve a negar isso?

Acho que vc deve ter confundido o tópico amigo!

Pois é, confirmando o que eu disse, você está visivelmente irritado e não está em condições de discutir nada.
Vou seguir o exemplo dos que tentaram conversar com você e não conseguiram, e vou deixar de responder a esse tópico.

Acho que Hibernate foi um exemplo infeliz. Não considero ele um dogma da igreja, mas concordo que ele revolucionou ORM pra Java e resolve desde o mais simples ao mais complexo. A questão do commit para select, que segundo o Paulo pode afinal ter um motivo, sempre me revoltou um pouco, por isso que eu acabei me empolgando na resposta.

Uma coisa é um Hibernate da vida outra coisa é um simples gerador de queries. Para quem vai trabalhar com JDBC puro se torna essencial um gerador de queries para ajudar o cara nas tarefas básicas. É apenas pra isso que serve o MentaBean, para ajudar o pobre-coitado que não sabe ou não quer usar Hibernate. Se ele já sabe então melhor ainda pra todo mundo!

Acho que o que o autor queria falar, e eu concordei, é que toda abstração é sempre bem vinda e isso não deve ser considerado reinvenção de roda. Pra que inventar o carro se já tinha charrete? (Não vai pensar que o primeiro carro andava a 80 km por hora, pois nem rua tinha!)

tnaires:

Pois é, confirmando o que eu disse, você está visivelmente irritado e não está em condições de discutir nada.
Vou seguir o exemplo dos que tentaram conversar com você e não conseguiram, e vou deixar de responder a esse tópico.

Se não tem argumentos o melhor que você faz realmente é ficar assistindo… e se eu realmente estou errado me mostre aonde.

Não há nada pra mostrar, as mensagens estão todas aí. Basta lê-las (a não ser, claro, que você as edite).

Já o Sérgio, em sua resposta, se mostrou bem mais maduro e equilibrado.
Obrigado pelo respeito.

Exatamente isso Sergio, abstrair nem sempre é reinventar a roda, eu não tenho pra que fazer outro framework se for manter a mesma complexidade, mas eu posso criar coisas mais fáceis.

O que parece é que alguns frameworks se preocuparam tanto com sua abrangência no sentido de funcionalidades que acabaram esquecendo sua principal função que é facilitar as coisas.

tnaires:

Já o Sérgio, em sua resposta, se mostrou bem mais maduro e equilibrado.
Obrigado pelo respeito.

Ok tnaires, acho que peguei pesado realmente, peço desculpas pelo ocorrido.

Ok cara, às vezes as pessoas se desentendem, mas o importante é que elas se entendam depois.
Vamos evitar que esse tópico seja bloqueado e continuar o assunto.

Eu nao disse que voce é obrigado a usar select dentro da query, só disse que ele tem um motivo para fazer isso, e voce disse que ele nao tinha.

Se o oracle tambem nao pensasse em transacoes que tem apenas selects, porque sera que existe o comando SET TRANSACTION READ ONLY??? E nao sei se dirty read e phatom read sao tao avancados assim.

Outra frase equivocada sobre banco de dados: “Leituras nunca são bloqueadas e nunca bloqueiam ninguém. Escritas bloqueiam apenas outras escritas.” Onde voce leu que o Oracle pensa assim? Fonte? O oracle nao tem isolation level Serializable? Nao tem level de Repetable Read? Ele nao tem Select for update? As escritas podem sim bloquear leituras, e as leituras podem bloquear TAMBEM. A

Voce falou mal da documentacao do hibernate, disse que fala coisas sem sentido, como essa de ter transacao em volta do select. Gostaria de saber se agora voce concorda que ela NAO esta errada, e que “a entrada nao esta podre”. Sei que o topico nao eh de hibernate, mas tem um monte de gente que conta com a sua credibilidade e te adimira, e nao gostaria que quem lesse suas mensagens acreditassem que “nao faz sentido um select dentro de uma query” ou que o oracle faz que escritas so bloqueiem escritas.

volnei:

emerleite:

Eu acho que em sistemas bem simples o hibernate ajuda pra caramba. As vezes não preciso nem me preoculpar com coisas mais cascudas. Simplesmente uso @Entity as vezes @Transient e fica tudo limpinho e bem facil. Para CRUDS então vira algo trivial.

Sinceramente não to visualizando o que tem de complexo nisto.

Ok, só que como citado XXX vezes esse tópico [size=24]NÃO É SOBRE HIBERNATE![/size]

Fala Paulo, eu sei que a mensagem foi direcionada ao Sergio, mas eu acho que tá ficando um mal entendido aqui que vou tentar explicar.

O Hibernate é um excelente framework e isso é fato, oque estamos dizendo é que a transposição de JDBC para Desenvolvedor que ele promove seja questionável mas não em funcionalidade e sim em complexidade. E esse não é um problema do hibernate e sim de vários frameworks talvez eu tenha citado ele simplesmente por ser um dos mais famosos. Mas a última coisa que eu queria era questionar o hibernate.

Espero que tenha sido claro.

Abraços

E pra que trabalhar com SQL puro hoje em dia a não ser para fazer acesso a um banco pré existente com uma estrutura tosca? O iBATIS já existe para ajudar nesse tipo de problema.

E por que esse “pobre-coitado” (que termo horrível para um desenvolvedor de software. Parece uma criança inocente ) não pode aprender o hibernate? Por que não querer aprender/usar o hibernate ?

Desculpe, isso não é flame-war, eu só quero entender o que você pensa sobre isso.

emerleite:

Segundo o tópico, Hibernate foi uma reinvenção da roda. Acho então válido.

O hibernate só foi citado nesse tópico como um exemplo, não era a intenção discutir sobre o framework.

Talvez tenha então e eu te agradeço por esclarecer isso. Mas me pareceu um caso bem particular e avançado para ser o default da coisa.

http://www.wisc.edu/drmt/oratips/sess001.html (de 1997)

http://books.google.com/books?id=Xkbl0Prv83cC&pg=RA1-PA286&lpg=RA1-PA286&dq=readers+"don+t"+block+oracle&source=web&ots=FzxReo8dLp&sig=JztpJAUXzVo7NTGvPlkfhqCl0F8

Concordo que não está errado, mas acho que está mais complexo do que deveria ser, ou seja, transaction em volta de select é desnecessário na grande maioria dos casos.

Sobre o Oracle, vide as fontes acima.

Como qualquer um as vezes falo besteira e estou errado/enganado sobre certos assuntos, assim como vc, um cara altamente capaz parece que estava errado em relação ao locking do Oracle. Acho que basta bons e educados argumentos para convencer as pessoas a olhar a coisa atrav
es de um novo ponto de vista.

emerleite:

E por que esse “pobre-coitado” (que termo horrível para um desenvolvedor de software. Parece uma criança inocente ) não pode aprender o hibernate? Por que não querer aprender/usar o hibernate ?

Desculpe, isso não é flame-war, eu só quero entender o que você pensa sobre isso.

Voce nao leu o proprio texto que mandou Sergio!!! LOGO abaixo ele deixa CLARO que ele esta falando de locks em arquivos das tabelas INTEIRAS. O livro é pro administrador unix/linux, por isso ele esta dando detalhes de file system! Nao estamos falando de file system, correto? Isolation level nada tem com file system, pouco importa como ele esta fazendo no sistema operacional! Voce simplesmente traduziu uma frase sem ler o paragrafo abaixo!!!

Vamos ao site da propria oracle, e ver um exemplo que tenha level READ COMMITTED ou maior:

Claro que um update pode travar sim outras leituras!!!

http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html

Entao cuidado com essa frase: “Leituras nunca são bloqueadas e nunca bloqueiam ninguém. Escritas bloqueiam apenas outras escritas.”" Apesar de ser como voce disse que pensa, definitivamente nao é como o Oracle pensa. Ele ate pode internamente fazer locks diferentes, ou evitar locks e depois retirar deadlocks, mas o efeito vai ser o de haver um lock.

Se o que voce esta querendo dizer eh que na maioria das aplicacoes as vezes a gente nao precisaria de tantos locks, ai eu concordo… como eh o caso la do hibernate. Sao sistemas raros que precisamos realmente evitar phantom reads

Como ja desde muito antes de inventarem Java ja falavam

Nada se inventa apenas se copia e melhora ou se “trasnforma”
ou seja reinventar algo seria como por exemplo refazer um codigo que faz amais do que o outro com as mesmas coisas

ou seja a roda, roda não importa quao nova ou antiga ela roda e se eu fizer uma roda novinha ele continua sendo roda

assim como o hibernate continua sendo Java só que serve como atalho para algumas coisas.

Não ninguem está reinventando a roda e apenas sim tentando a aprimora-la, cabe a cada um descidir se ela é melhor para fazer oque você precisa ou não.

Boa pergunta. Não sei a resposta. Porque não querer aprender Hibernate, Spring, iBatis, Mentawai, VRaptor, Struts, Tapestry, etc.

Não tenho dúvida de que quanto mais vc sabe melhor é. Problema é que o tempo é escasso e cada pessoa está num determinado nível técnico. Existem pessoas que começaram a programa em Java agora, outras que programam a uma década. Outros que conhecem SQL, outros que nunca viram SQL. E por aí vai…

O problema é que o mundo Java abusou dessa sua pergunta e criou-se a salada de frameworks. Para fazer uma aplicação web java era muito simples, bastava usar Struts, JSTL, Hibernate, C3P0, Commons Validation, Spring, Commons Email, Commons File Upload, JAAS, Tiles, Log4J, OSCache, etc. Por que não saber usar e integrar esses frameworks? Isso não colabora nem um pouco para a simplicidade e a produtividade, principalmente dos menos experientes.

vou parar de falar ja que agora todos concordam em amar o Hibernate incodicionalmente

volnei:

Na minha opinião, vou usar um termo mais antigo que reinventar a roda, nem Cristo agradou a todos, acha que o hibernate vai agradar??

Novamente, grandes idéias surgem quando você avalia algo e cria algo melhor. Mas no caso do hibernate, o que seria tão problemático que não pudesse ser modificado/ajustado/adicionado no código deste, visto que é aberto? Esse algo melhor que você vai colocar pode ser algo que já existe, mais simples que o seu, mais testado e mais maduro. Não é melhor estudar o que já tem e se você tiver uma ídeia que seja bem diferente do que já tem, ou que não seja possível implementar em algo já existente por questões arquiteturais do core, em fim, sei lá o que, você cria novo?

Paulo Silveira:

Voce nao leu o proprio texto que mandou Sergio!!! LOGO abaixo ele deixa CLARO que ele esta falando de locks em arquivos das tabelas INTEIRAS. O livro é pro administrador unix/linux, por isso ele esta dando detalhes de file system! Nao estamos falando de file system, correto? Isolation level nada tem com file system, pouco importa como ele esta fazendo no sistema operacional! Voce simplesmente traduziu uma frase sem ler o paragrafo abaixo!!!

Vamos ao site da propria oracle, e ver um exemplo que tenha level READ COMMITTED ou maior:

Claro que um update pode travar sim outras leituras!!!

http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html

Não Paulo, tenha a humildade de assumir que vc estava equivocado quanto a isso. Qualquer um pode estar errado sobre alguma coisa. Isso não é pecado, por favor.

Ou como eu fiz, coloque o texto, com as fontes e de preferencia cite duas fontes distintas. Eu li muito bem o parágrafo anterior e o posterior. Acho que quem não leu direito foi vc. Vou postar aqui o parágrafo seguinte que vc disse que eu não li.

E veja que a primeira fonte (sim, citei duas) [color=blue]é de 1997 e já afirmava isso[/color], sem observações ou poréns.

Vou achar mais uma fonte a esmo aqui no Google:

Fonte: http://www.adp-gmbh.ch/ora/concepts/undo.html

Mais uma fonte: http://www.burtleburtle.net/bob/other/sql.html

Isso é antigo do Oracle e ele foi o pioneiro. Acho que agora o MySQL e outros DB já possuem esse comportamento, ao meu ver, bem importante.

Acho que vc ainda não entendeu o tópico! Um exemplo é um exemplo nada mais do que um exemplo. Po pessoal relaxa, vou repetir NINGUEM TÁ QUESTIONANDO O HIBERNANTE!

É a idéia do tópico, só que nem sempre pode-se implementar algo em cima do que já existe…

Repare que o proprio site da oracle esta falando sim de writer bloquear reader. Isso é o que voce ve no final. Assim como o SELECT FOR UPDATE locka tambem. Te importa se la dentro ele fez macumba ou tirou xerox da linha a cada modificacao?

Voce esta falando da implementacao interna do Oracle. como disse ali " Ele ate pode internamente fazer locks diferentes, ou evitar locks e depois retirar deadlocks, mas o efeito vai ser o de haver um lock". Voce disse que pensa como a Oracle faz, entao voce fica anotando no mentabean todo o historico de modificacoes no objeto durante uma transacao, assim se alguem precisar ver a versao antiga (pra nao ocorrer dirty read) voce recalcula a versao antiga e a mostra, para nao ter de usar um syncrhonized em cima daquele objeto? Isso é realmente avancado e complicado, alem de gastar muita memoria, eu fico com o synchronized para obter o mesmo efeito.

Realmente interessante essa implementacao da oracle, com o objetivo de fazer os locks que precisamos, nao conhecia. Parece aqueles Log Ahead First para recuperar banco de dados do crash.

Acho que a pergunta inicial foi mal formulada. Não existe necessariamente uma relação entre reinventar a roda com abstrair a complexidade.

O problema que sempre reinventam a roda quando precisam que o framework X tenha strings azul e não verde é uma apenas uma prova que construir frameworks, ou qualquer peça de software reutilizável, é uma tarefa difícil que exige tempo e experimentação. Basta analisar os frameworks Java do começo do século e alguns que temos hoje para notar a diferença.

Falo das características fundamentais, axiomáticas até, que todo framework deve seguir: extensibilidade e poder ser composto. Notem que as duas apesar de próximas tem diferenças marcantes. Um framework extensível permite que seu comportamento seja plenamente customizavel, enquanto ao permitir ser composto, garante que ele seja, por assim dizer, apto a ser consumido por outro framework.

O Hibernate é um ótimo exemplo de como um framework deve ser construído e isso só aconteceu na versão 3.0, então não é fácil. É muito fácil construir um framework em cima do Hibernate. Por exemplo, implementar o MentaBeans com Hibernate seria muito mais simples que da forma como está. Implementar um modelo semelhante ao ActiveRecord e expor esses objetos a um interpretador de JS também é super simples, isso tudo apenas programando em cima do Hibernate.

O problema de reinventar a roda é quando os frameworks existentes foram criados pensando exclusivamente no usuário final e não que serão consumidos por outros. Isso é um erro grave que até hoje ainda é uma praga no mundo Java.

Fui lá fuçar a sua fonte no site da Oracle, por curiosidade mesmo. Doeu o cérebro, mas encontrei isso aqui na tabela que fala que o writer está bloqueando o read.

http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html

Acho que ali ele está demonstrando todos os isolations levels e como os outros bancos de dados se comportam para depois falar que o Oracle é o bom!

Não tenho certeza, mas acho que o MySQL e outros já possuem essa característica que no passado já foi o trunfo do Oracle, afinal alguma coisa tinha que justificar pagar 100 mil reais por um software.

saoj:

Paulo Silveira:

Repare que o proprio site da oracle esta falando sim de writer bloquear reader.

Não tenho certeza, mas acho que o MySQL e outros já possuem essa característica que no passado já foi o trunfo do Oracle, afinal alguma coisa tinha que justificar pagar 100 mil reais por um software. :-)

Tambem acho. Esses caras se copiam assim como Java e .NET se copiam.

louds:

O problema de reinventar a roda é quando os frameworks existentes foram criados pensando exclusivamente no usuário final e não que serão consumidos por outros. Isso é um erro grave que até hoje ainda é uma praga no mundo Java.

Frameworks que são usados por outros desenvolvedores é o que dá mais trabalho, principalmente quando ele não tme outra escolha. Trabalhei com isso, fazendo o framework que seria utilizado desenvolvimento de vários outros produtos.

O Hibernate tem a facilidade de ser apenas java (tá, também tem para C#, mas com essas atualizações do VS2008 e a vinda do LINQ não sei como vai ficar) e na minha opinião as primeiras versões não foram muito bem discutidas antes da implementação, mas as versões mais recentes estão ótimas, o que mostra a evolução das pessoas e a proposta de alguns projetos Open Source.

Voltando ao tópico, "reinventar a roda" as vezes é uma necessidade, voltando ao exemplo de quando eu fazia o framework, tinha que criar bibliotecas em C (BREW), Java (J2ME) e C (SYMBIAN). assim, o mesmo código "compilava" em todas essas plataformas (era necessário trocar . -> ::, etc. mas era um avanço) e algumas coisas tinha que ser adaptadoas em cima das implementações que já existiam (do proprio SDK e dos diversos frameworks q já existiam). Se você rpecisa de algo, vai lá e faz. Não adianta cadastrar seu problema no forum do framework, escrever no JIRA porque o andar desses projetos pode não atender aos seus prazos.

Paulo Silveira:

saoj:

Paulo Silveira:

Repare que o proprio site da oracle esta falando sim de writer bloquear reader.

Não tenho certeza, mas acho que o MySQL e outros já possuem essa característica que no passado já foi o trunfo do Oracle, afinal alguma coisa tinha que justificar pagar 100 mil reais por um software. :-)

Tambem acho. Esses caras se copiam assim como Java e .NET se copiam.

Assim como a Oracle copiou o conceito de triggers da Sybase, e por aí vai.

Hoje no Oracle schema e user é a mesma coisa, já em MySQL, PostgreSQL são coisas distintas; eu acho que em breve veremos numa nova versão do Oracle essa “grande inovação” de ter isso separado. Até pouco tempo atrás nem tabela temporária tinha e até hoje coisas básicas, como por exemplo uma coluna do tipo boolean não existe e somos obrigados a usar gambiarras.

Sobre a discussão de lock, o que é interessante do Oracle é que tudo isso ele implementa internamente, vc faz um UPDATE de 10 linhas e pronto, ele já locou essas linhas para a sua sessão, somente você vê as alterações fazendo SELECT, mais ninguém. Se outra pessoa fizer um update em algumas dessas 10 linhas, a sessão dela vai esperar a sua commitar a transação ou desfazer com rollback.

O resto deste tópico tem até algum mérito mas eu discordei do que você dise com relação ao Hibernate. Este tópico não é ‘só seu’, se você não está interessado em discutir suas opiniões não as expresse em um fórum público.

AHm? Todas são linguages Orientadas a Objetos de uso eral. Todas azem a mesma coisa, de maneiras diferentes.

Ahm? Você quem falou que HQL vira SQL, então dá pra fazer tudo em SQL. Eu concordei e ainda falei que Bytecode vra código de máquina, então vamos fazer tudo em código de máquina. O que framework web tem a ver com isso?

volnei:

Nossa isso é totalmente relativo, não tem como falar que não funciona… à não ser que exista algum framework pronto chamado "caseiro" eu acho que se vc implementar bem vai funcionar.

Pois é, eu aposto que quando você tentar vai mudar de idéia. Pense num grafo simles, um administrador <-> grupo <-> usuario. Agora faça consultar lazy-loaded que tragam todos os usuários de um grupo, pegue todos os grupos de todos estes usuários num conjunto e depois retorne todos os administradores de todos os grupos que esses usuários pertencem a.

CGLIB faz manipulação de bytecode, não lazy loading. Por favor, conheça a ferramenta antes de criticar.

Se você não tem queries polimórficas como vai ter polimorfismo? Como eu consigo uma consulta que me traga todas as instâncias da classe Usuario e de sas subclasses, segundo o modelo uma-tabela-por-classe ?

Se você não gosta disso basta criar um wrapper.

Hibernate é Java então dizer que tudo que se faz com ele se faz ‘em java’ nao faz sentido. Se você quiser reimplementar o Hibernate -ou um subset dele- em cada projeto esrevendo JDBC boa sorte.

pcalcado:

Hibernate é Java então dizer que tudo que se faz com ele se faz ‘em java’ nao faz sentido. Se você quiser reimplementar o Hibernate -ou um subset dele- em cada projeto esrevendo JDBC boa sorte.

O caso é um pouco mais curioso, pois não usando nenhum framework de ORM não é possivel implementar persistencia em um RDBMS só (apenas) com Java, já que não tem como escapar de usar SQL com JDBC. SQL não é Java, por mais que se queira argumentar, não é. Já com Hibernate, é sim possivel implementar só com Java e nenhuma outra linguagem externa. Esse argumento contra Hibernate que com “só Java” é mais simples/facil/produtivo me faz rir pela própria falha na sua construção.

Juro que eu não entendi esse negócio de “reinventar a roda” que o Volnei anda dizendo tanto. É só uma expressão sem sentido pra dizer que determinada criação é ruim, sem usar argumentos sólidos!

O interessante é que, enquanto “reinventar a roda” tem um sentido depreciativo, a palavra “reinventar” sozinha tem um sentido positivo, de rejuvenecimento… É claro que, para o Volnei, tudo parece que é apenas “reinventar a roda”, o que é uma pena. Imagine a época em que foi criado o C para substituir a escrita em Assembly, foi uma reinvenção ou uma reinvenção da roda? E a criação do Java para substituir o C e C++? E a criação dos web frameworks para substituir a escrita direta em Servlets ou CGIs? Tudo isso foi reinvenção da roda?

Ah, mas tem aquele argumento manjado de que Java tem zilhões de frameworks, todos fazendo coisas parecidas entre eles. Mas amigo, o mundo do software livre é assim. Vários desenvolvedores criaram seus frameworks ou suas bibliotecas acreditando ter ideias interessantes pra comunidade. E não dá pra barrá-los dizendo: “Desculpe cara, não dá! Um outro framework faz exatamente o que você faz.”. Fosse assim e a liberdade iria pro saco! A comunidade acaba fazendo suas escolhas, claro! Mas ninguém é obrigado a segui-las se achar que fazendo diferente dos demais, vai fazer melhor.

Mesmo não concordando com a FORMA que o volnei demonstra seus argumentos, acredito que algumas pessoas estão aparentemente destorcendo seu post, o que ele parece querer é verificar se a desculpa de “reinventar a roda” não seria algo prejudicial, acabando por não permitir que ideias mais simples da mesma coisa possam surgir. No quisito “exemplo” do post é que o volnei pecou, foi falar logo do Hibernate!!!

louds:

O caso é um pouco mais curioso, pois não usando nenhum framework de ORM não é possivel implementar persistencia em um RDBMS só (apenas) com Java, já que não tem como escapar de usar SQL com JDBC. SQL não é Java, por mais que se queira argumentar, não é. Já com Hibernate, é sim possivel implementar só com Java e nenhuma outra linguagem externa. Esse argumento contra Hibernate que com “só Java” é mais simples/facil/produtivo me faz rir pela própria falha na sua construção.

Acho que você não leu tudo até aqui, mas quando me refiro a só java quero dizer algo que implementa alguma especificação, no caso JDBC e vc entendeu isso. Ninguem aqui é contra o hibernate, o tópico só foi criado para que pudessemos discutir sobre a abstração de uma determinada complexidade e como ela é entregue ao desenvolvedor tanto no hibernate como em qualquer outro framework.

Certo, o tópico não é só meu mas eu acho que seria no mínimo respeitoso manter o assunto com o qual ele foi iniciado e você moderador?? oq acha??

O objetivo do java é na minha concepção ser uma linguagem altamente portável o que a torna diferente do c# por exemplo WORA…

Você entendeu sim, quando você foi irônico no seu comentário que era possivel fazer tudo em assembly e realmente é, eu apenas disse que tambem é possivel usar uma quantidade escumunal de frameworks e em ambos oque tem que prevalecer é o bom senso, mas honestamente se não são capazes de seguir o assunto de um tópico nao posso exigir muito disso neh??

OK, todos tem direito de se expressar, mas se eu não mudar de idéia? Se você não tem capacidade para abstrair oque falou continua usando hibernate, mas não menospreze os outros.

E o hibernate o usa para fazer o lazy loading, ou seja dá na mesma!

Nossa a única forma de fazer isso é assim??? Você é que precisa conhecer um pouco mais de programação.

Ou criar um framework em cima desse?? Nossa vocês estão parecendo doentes ao falar do hibernate…

Não estou questinando o hibernate dá um pesquisada no tópico quantas vezes eu disse isso e vai ver, estou apenas questionando a forma que o desenvolvedor recebe ele, ou seja o que tem que ser by hand é realmente simples.

PCalcado, eu sinceramente encerro a discussão sobre qualquer assunto relacionado a hibernate aqui, eu repeti várias vezes que o objetivo não era esse e sequer tenho conhecimento para discutir isso a fundo. Só vou te dizer uma coisa, seus comentários são pejorativos e sinceramente não é postura de alguem que está a frente de uma comunidade, cuidado com isso. Se quiser responder a isso fique a vontade eu sequer vou me dar o trabalho de ler.

Leonardo3001:

Juro que eu não entendi esse negócio de “reinventar a roda” que o Volnei anda dizendo tanto. É só uma expressão sem sentido pra dizer que determinada criação é ruim, sem usar argumentos sólidos!

Nossa você não leu mesmo o tópico, sugiro uma leitura antes de tecer seus comentários.
Primeiro pelo fato de avaliar a expressão “reinventar a roda” e não a palavra reinventar ok?? voce sabe o significado disso não é???

É claro que, para o Volnei, tudo parece que é apenas “reinventar a roda”
Acho que está me confundindo… mais uma vez, leia o tópico antes e se ver que errou tenha coragem de criticar a pessoa certa.

Leonardo3001:

Ah, mas tem aquele argumento manjado de que Java tem zilhões de frameworks, todos fazendo coisas parecidas entre eles. Mas amigo, o mundo do software livre é assim. Vários desenvolvedores criaram seus frameworks ou suas bibliotecas acreditando ter ideias interessantes pra comunidade. E não dá pra barrá-los dizendo: “Desculpe cara, não dá! Um outro framework faz exatamente o que você faz.”. Fosse assim e a liberdade iria pro saco! A comunidade acaba fazendo suas escolhas, claro! Mas ninguém é obrigado a segui-las se achar que fazendo diferente dos demais, vai fazer melhor.

Olha, pessoal não me levem a mal, mas tenho que desabafar.

1. Se vocês não entenderam o tópico, diga apenas não entendi antes de tirar conclusões precipitadas.
2. Jamais menospreze alguem que você sequer conhece.
3. Leia sempre o tópico inteiro antes de entrar e criticar a pessoa que tem menos mensagens no fórum.
4. Incentivar ou desestimular pode ser confundido quando se usa determinados termos.
5. A melhor maneira de discordar de alguem é expondo e não impondo e sempre com respeito.
6. Esse tópico não tinha intenção de discutir sobre hibernate.

PCalcado, não isso não serve só para você mas honestamente, esperava um pouco mais de um dos líderes de uma comunidade tão importante.

Encerro minha participação neste tópico sem sequer ter discutido o que eu havia proposto, por conta de alguns fanáticos o assunto do tópico foi totalmente desfigurado ao longo das ofensas e tentativas de se retornar ao assunto em pauta. Talvez eu tenha me expressado mal em alguns momentos e confesso que esse não é o meu forte, mas tenho certeza que não faltou empenho em tentar explicar.

Se alguem se sentiu ofendido aqui, peço desde já minhas desculpas.

Um abraço a todos.

Talvez seja você que não sabe respeitar a opinião dos outros. Lembre-se:

1. o tópico não é seu;
2. o fato de abri-lo não lhe dá direito de ter poderes sobre os outros;
3. o Calçado é irônico sim, mas suas argumentações (a do Calçado, não a de você, Volnei!) são consistentes e não ficam mudando ao sabor da discussão;
4. eu li todo o tópico sim, afirmar o contrário não é justificativa para invalidar minhas argumentações;
5. não tenho pena de pessoas que se fazem de vítima.

Passar bem.

Leonardo3001:

Talvez seja você que não sabe respeitar a opinião dos outros. Lembre-se:

1. o tópico não é seu;
2. o fato de abri-lo não lhe dá direito de ter poderes sobre os outros;
3. o Calçado é irônico sim, mas suas argumentações (a do Calçado, não a de você, Volnei!) são consistentes e não ficam mudando ao sabor da discussão;
4. eu li todo o tópico sim, afirmar o contrário não é justificativa para invalidar minhas argumentações;
5. não tenho pena de pessoas que se fazem de vítima.

Passar bem.

Respeitar a opinião dos outros?? Leia suas mensagens… afff

Obrigado, mas isso não muda em nada…

1. Desde quando meu nome está como autor eu acho que ele é meu, direitos autorais?? conhece??
2. Eu reinvindiquei poderes tambem nesse tópico?? Onde?? Você tá vendo demais ou de menos…
3. É segurança dele? Me diga onde o pcalcado disse algo referente ao tópico que foi consistente?
4. Se tivesse lido não tinha dito tanta besteira, ou tinha? Se disse que eu estou errado está tendo inconsistencias e se disse que os que tem opinião diferente da minha estão certos segue inconsistente…
5. Eu tenho pena de você.

Acho que o louds se referia a poder usar anotações (Java) para mapeamento e Criteria API (Java) para realizar consultas. Bom, só com JDBC não tem como escrever apenas código Java, tem?

Mas entendi o ponto do tópico. Minha opinião: tenha bom senso - e bons argumentos - para decidir usar ou não algum framework/abstração.

valeuz…

volnei:

…
HQL é java? Qual JSR??
…

JSRs:
317: JPA 2.0 -> http://jcp.org/en/jsr/detail?id=317 ( podemos contar a HQL aqui! )

Java Persistence API 2.0:

Section 2: Request

2.1 Please describe the proposed Specification:

The Java Persistence API is the Java API for the management of persistence and object/relational mapping for Java EE and Java SE environments.

The purpose of the Java Persistence 2.0 specification is to augment the Java Persistence API to include further features requested by the community, including additional object/relational mapping functionality and query language capabilities, a criteria-based query API, and standardization of features currently designated as optional, and to align it with related JSRs that are currently in-process and/on in-plan for the Java EE 6 timeframe.

Aspects that should be considered by the Expert Group for inclusion in this work include, but are not limited to, the following:

* Expanded object/relational mapping functionality, including greater flexibility in combining existing mapping options, support for collections of embedded objects, multiple levels of embedded objects, ordered lists, combinations of access types, etc.
[b]* Additions to the Java Persistence query language[/b]
[b]* An API for "criteria" queries[/b]
* Standardization of sets of "hints" for query configuration and for entity manager configuration
* Standardization of additional metadata to support DDL generation and "Java2DB" mapping
* Expanded pluggability contracts to support efficient passivation and replication of extended persistence contexts in Java EE environments
* Standardization of additional contracts for entity detachment and merge, and persistence context management
* Support for validation

The goal of the Expert Group will be to investigate these issues and identify and pursue directions for enhancement for the overall programming model and facilities of the Java Persistence API.

Até!

jack_-_ganzha:

Mas entendi o ponto do tópico. Minha opinião: tenha bom senso - e bons argumentos - para decidir usar ou não algum framework/abstração.

valeuz…

Ladrão de resposta.

Volnei, seu problema que você iniciou um tópico com um assunto de curso de redação “Gostaria de discutir a influencia do voo dos patos na programação de sistemas de grande porte sobre a ótica da fase azul do Picasso”. Reinventar a roda é sadio e importante, faz parte do processo evolutivo, devemos abraçá-la e apreciar o Darwinismo envolvido. Fazemos isso a vida toda ou você pulou a etapa de andar e foi direto para levitação?

Acho que o louds se referia a poder usar anotações (Java) para mapeamento e Criteria API (Java) para realizar consultas. Bom, só com JDBC não tem como escrever apenas código Java, tem?

Mas entendi o ponto do tópico. Minha opinião: tenha bom senso - e bons argumentos - para decidir usar ou não algum framework/abstração.

valeuz…

Olá, sim ele tem razão mas não era sobre isso a discussão. Como eu disse eu nem tenho conhecimento suficiente de hibernate para falar sobre a idéia da discussão tinha outro sentido, mas o fanatismo fala mais alto.

louds:

jack_-_ganzha:

Mas entendi o ponto do tópico. Minha opinião: tenha bom senso - e bons argumentos - para decidir usar ou não algum framework/abstração.

valeuz…

Ladrão de resposta.

Volnei, seu problema que você iniciou um tópico com um assunto de curso de redação “Gostaria de discutir a influencia do voo dos patos na programação de sistemas de grande porte sobre a ótica da fase azul do Picasso”. Reinventar a roda é sadio e importante, faz parte do processo evolutivo, devemos abraçá-la e apreciar o Darwinismo envolvido. Fazemos isso a vida toda ou você pulou a etapa de andar e foi direto para levitação?

Se esse assunto fosse tema de redação então vocês todos estariam reprovados pois fugiram o tema.
Mas a idéia era discutir até que ponto oque temos hoje pode ser melhorado, mas quase tudo que eu falei aqui foi distorcido e eu não to entendendo o porque disso. Se eu citei o exemplo do hibernate é pq ele é o mais famoso dos frameworks e tambem citei struts mas ninguem falou nada. Acho que tinha tudo pra ser mais uma boa discussão envolvendo talvez até idéias para melhoria doque temos mas o fanatismo por alguns frameworks é que predominou. Por diversas vezes eu tentei voltar ao assunto inicial mas parece que quando se fala em framework só se pensa em hibernate, quando se fala em melhorar as coisas o assunto acaba do hibernate, seria então o hibernate uma ferramenta que não pode ser melhorada ou o contrário disso?

Sempre achei que o pessoal aqui era bem disposto a discutir idéias, mas com tantas argumentações irônicas me decepcionei bastante.

saoj:

emerleite :

Por que não querer aprender/usar o hibernate ?

Boa pergunta. Não sei a resposta. Porque não querer aprender Hibernate, Spring, iBatis, Mentawai, VRaptor, Struts, Tapestry, etc.

Não tenho dúvida de que quanto mais vc sabe melhor é. Problema é que o tempo é escasso e cada pessoa está num determinado nível técnico. Existem pessoas que começaram a programa em Java agora, outras que programam a uma década. Outros que conhecem SQL, outros que nunca viram SQL. E por aí vai…

O problema é que o mundo Java abusou dessa sua pergunta e criou-se a salada de frameworks. Para fazer uma aplicação web java era muito simples, bastava usar Struts, JSTL, Hibernate, C3P0, Commons Validation, Spring, Commons Email, Commons File Upload, JAAS, Tiles, Log4J, OSCache, etc. Por que não saber usar e integrar esses frameworks? Isso não colabora nem um pouco para a simplicidade e a produtividade, principalmente dos menos experientes.

É certo que no seu caso, como você trabalha direto com o Mentawai e Mentabean, você não precisa neste momento de conhecimentos de Hibernate, mas suponhamos que seu framework não existisse? Você acha mesmo que ia conseguir se manter no mercado sem utilizar Hibernate?

Hoje em dia ainda existem empresas que deveriam aproveitar o uso desta ferramenta e não utilizam por filosofias conservadoras ou algo do tipo, mas são lugares que eu não recomendo alguém buscar uma oportunidade.

Pra quem é do Rio de Janeiro e quiser ver o básico haverá uma palestra ministrada pelo Paulo Silveira na próxima terça-feira no RIOJUG. Existe outro tópico anunciando.

http://www.guj.com.br/posts/list/79723.java

No caso do Hibernate.

Você cria um sistema de gerenciador de entidades, isso se estiver trabalhar com JPA por baixo, ou cria um sistema de gerenciador de sessão, se não estiver trabalhando com JPA por baixo.

SessionFactory ou EntityManager

Daí fazemos o seguinte, com o JDBC padrão criamos então a nossa classe de conexão que obtemos a instância de um DriveManager

depois disso tratamos os eventos em DAOs (Data Access Object), geralmente usamos da seguinte forma, para cada tabela (classe ou entidade como queira chamar) declaramos um DAO. Temos portanto na nossa aplicação:

Voltando ao hibernate.

Crio um JPAUtil, ou simplesmente um DAO genérico, do qual posso abstratir as funcionalidades de Cliente, Dependente, Usuario, Produto, Fornecedor e Log.

Bom. Fazemos nossas entidades herdarem uma classe model em comum, dessa forma tornamos generico o processo de CRUD e de outras atividades.

:arrow: E se mudar o banco??

Mudando o banco, em tese apenas precisamos mudar a nossa configuração inicial, que pode estar declarada em um hibernate.cfg.xml, em um persistence.xml, em um arquivo properties, podemos “dá um overring” nas configurações em runtime, em fim, temos essa liberdade de tratar e alterar a configuração.

:arrow: E se eu quiser usar SQL nas consultas?

Pode-se fazer, apesar que perde inclusive um dos conceitos fundamentais do hibernate ou iBATIS que é a crossover plataform. Independência de banco de dados.

:arrow: Posso fazer qualquer tipo de consulta?

Pode sim, basta saber criar os relacionamentos, usar a Criteria, find, Criterion, NamedQueries, em fim, usar o que o hibernate disponibiliza para você.

:arrow: E se mudar um campo da tabela?

Como você não tem toneladas de DAOs o seu impacto será MUITO menor que se você estivesse usando o padrão normal JDBC.

Em fim, há frameworks que vêm para ajudar e outros que concordo que só são para…

O que eu vejo acontecer no mundo OS é que se o Zé das Couve precisa de uma funcionalidade não diponibilizada pelo framework “Tilanga”, ele vai lá e cria o framework dele, ao invés de entender a “Tilanga” e contribuir para o seu desenvolvimento.

Cria as variedades, mas ‘afasta’ a comunidade. Enfim, uma faca de dois legumes. (;

Mas é complicado de se implementar um framework fácil de se extender. Você pega o Spring MVC mesmo, ele é extremamente extensível, mas entender ele é complicado pra quem só mexeu com frameworks action comum, só de ver a quantidade de controllers que estão disponíveis pra serem utilizados o cara se assusta.

Mas isso ocorre ao meu ver porque nunca existe/existirá um concenso sobre algo, uma funcionalidade crucial para você pode parecer banal para os outros e é aí que começa a briga. Um exemplo, se todo mundo gostasse de struts não teria porque o Sergio criar o Mentawai, mas ele viu deficiencias no struts e as implementou no mentawai, assim como o próprio tem suas deficiencias em relação ao struts. É por isso que eu defendo que os frameworks devem ser extremamente plugáveis e polimórficos. Mas como fazer isso? Essa é uma boa questão mas talvez algo como é no eclipse, você adiciona suporte ao que você quer apenas.

Olha, lá em “Design Patterns” os caras já avisavam que criar código orientado a objetos era difícil e mais difícil ainda era criar código flexível orientado a objetos, isso não é uma coisa trivial de se fazer não e quando você consegue isso em Java ou é a custa de muita mágica ou de interações complexas demais entre os objetos.

Pegue JSF por exemplo, ele é tão extensível que chega a ser absurda a complexidade de se criar componentes (hoje já existem frameworks pra se criar componentes em JSF!), a complexidade e flexibilidade demasiadas tornaram o framework complexo demais.

Flexibilidade é uma coisa que tem que ser medida com muito cuidado, especialmente em aplicações Java onde a própria linguagem não ajuda muito você a fazer esse tipo de coisa.

Sim, mas veja o exemplo do struts, ele vem com o básico e oque você quiser você adiciona através de plugins… é disso que eu estou falando se eu não quero uma determinada funcionalidade eu não preciso usá-la ou sequer tela em meu projeto. Isso é flexibilidade e isso é um incentivo para se criar novas funcionalidades, poxa o struts não deixa fazer aquilo, mas eu posso criar um plugin e plugá-lo, mas nem todo mundo pensa assim entendeu, cria-se frameworks sem analizar a sua expansibilidade. Em resumo acho que frameworks deveriam ter o mínimo de funcionalidades e serem plugáveis…

Mas aí mata o que você disse antes, veja só:

O WebWork fazia o que o Struts fazia e era melhor, tinha o esquema de interceptors e ainda tinha injeção de dependências direto no framework, porque então foram fazer Spring MVC, Mentawai e todo o resto se eles não faziam nada de diferente?

Eu, pessoalmente, não lembro de ter utilizado um framework Java que não fosse ao menos “levemente” extensível, por plugins, configuração ou coisas do gênero, o que não existe (e nunca vai existir) é um jeito padrão de se colocar plugins num framework, porque cada um tem o seu próprio domínio e “jeito” de se fazer as coisas.

Qual framework Java você usou não é plugável o suficiente? O que era que você queria?

O caso é quando um framework/biblioteca que parece fazer a mesma coisa que um já existente, mas na verdade tem um propósito diferente.

Ex: O nosso Hibernate (caraca se contarmos as vezes que foi mencionado só neste tópito …) e o iBATIS. São frameworks ORM que tem propósitos diferentes.

O iBATIS é mais facil para trabalhar com o Banco legado com estrutura bem tosca ou se você já tem uma aplicação cheia de SQLs nos DAOs mas quer retirar esses SQLs do .java e colcoar em um arquivo XML separado e retirar os 1000 comandos set que estão sendo usados para popular os objetos.

Em uma aplicação dessa já pronta, aplicar o hibernate é muito mais complicado e o iBATIS pode ser uma alternativa bem interessante para melhorar a bagunça.

Beleza, mas porque não incorporar essas funcionalidades ao hibernate? como se fosse um plug-in. tem tanto framework que fica dificil lembrar a sintaxe de todos.

Porque esse não é o objetivo do Hibernate e isso sempre foi deixado bem claro. Se você não tem um modelo “redondinho” no banco de dados, não use Hibernate.

Quem tenta agradar todo mundo, termina não agradando ninguém.

Maurício Linhares:

Porque esse não é o objetivo do Hibernate e isso sempre foi deixado bem claro. Se você não tem um modelo “redondinho” no banco de dados, não use Hibernate.

Quem tenta agradar todo mundo, termina não agradando ninguém.

Concordo demais com isso, faz bem manter o foco / propósito.

Hibernate é sim uma reinvenção da roda…

Mas é uma roda aro 20, de liga leve, diamantada, e com pneus yokohama…

A idéia é componentizar as coisas, eu tenho um framework para aplicações web, se eu quiser usar uma ferramenta ORM eu baixo o plugin ORM desse meu framework, se eu quiser usar freemarker ao invés de jsp eu baixo o plugin que faz isso, se não existir eu leio a especificação e o desenvolvo mas tem um único core controlando tudo, desde injeção de objetos a configurações. Não sei se isso se aplica ao hibernante, mas talvez algo assim, se eu quisesse HQL eu baixaria o plugin para HQL no hibernate, se eu quisesse usar Lazy Load eu baixaria o plugin para lazy load…

Acho que é mais ou menos isso…

Acho que caminhariamos mais rápido nas evoluções…

Mas existem coisas que são intrínsecas do framework, o Hibernate não poderia existir sem lazy-loading e sem HQL, não adianta ter um framework que não faça nada sozinho, o básico da funcionalidade dele tem que estar implementada (que no Hibernate, por exemplo é fazer CRUD, poder fazer selects sem usar SQL, usando HQL e criteria, e ter lazy-loading de entidades sempre que necessário). O que for além disso é complemento.

No Spring MVC, por exemplo, quando você quer usar o freemarker, basta trocar uma linha de configuração lá dizendo que o seu controller usa o freemaker, ele já sabe o que você vai fazer. Se você não vai usar FreeMaker, Velocity ou JSP com JSTL (que são os que já vem com plugins por padrão no Spring MVC) você pode escrever o seu próprio plugin pra sua própria engine de template e dizer pro Spring MVC qual é a classe que gera as views. Ele é totalmente configurável e extensível, não só pra isso como pra muitas outras coisas.

Ainda não consigo entender o seu ponto, qual o framework que você achou que não era extensível o suficiente pro seu problema?

desculpem em desvirtuar o assunto do topico… mas apos ler alguns posts fiquei com uma grande curiosidade que aposto que muitos devem ter ficado… o que são reads phantom? pq abrir uma transação pra fazer select???

Maurício Linhares:

Olha, lá em “Design Patterns” os caras já avisavam que criar código orientado a objetos era difícil e mais difícil ainda era criar código flexível orientado a objetos, isso não é uma coisa trivial de se fazer não e quando você consegue isso em Java ou é a custa de muita mágica ou de interações complexas demais entre os objetos.

Pegue JSF por exemplo, ele é tão extensível que chega a ser absurda a complexidade de se criar componentes (hoje já existem frameworks pra se criar componentes em JSF!), a complexidade e flexibilidade demasiadas tornaram o framework complexo demais.

Flexibilidade é uma coisa que tem que ser medida com muito cuidado, especialmente em aplicações Java onde a própria linguagem não ajuda muito você a fazer esse tipo de coisa.

O Hibernate é um bom exemplo de framework extensível no qual boa parte da extensibilidade fica escondida do usuário comum. É possível customizar todas etapas do ORM e para quem usa não muda nada. Plugins não são necessáriamente a resposta para extensibilidade e ser composicional.

volnei:

A idéia é componentizar as coisas, eu tenho um framework para aplicações web, se eu quiser usar uma ferramenta ORM eu baixo o plugin ORM desse meu framework, se eu quiser usar freemarker ao invés de jsp eu baixo o plugin que faz isso, se não existir eu leio a especificação e o desenvolvo mas tem um único core controlando tudo, desde injeção de objetos a configurações. Não sei se isso se aplica ao hibernante, mas talvez algo assim, se eu quisesse HQL eu baixaria o plugin para HQL no hibernate, se eu quisesse usar Lazy Load eu baixaria o plugin para lazy load…

Acho que é mais ou menos isso…

Acho que caminhariamos mais rápido nas evoluções…

bobmoe:

LAZY e HQL a parte??? Você compraria um carro sem volante? e uma bicicleta sem roda?

Infeliz comparação, não se dirige um carro sem volante, mas se faz grandes coisas sem lazy load, e tambem existe a critéria que pode ser usada no lugar da HQL. Pra ser irônico tem que no mínimo saber oque está falando.

volnei:

bobmoe:

LAZY e HQL a parte??? Você compraria um carro sem volante? e uma bicicleta sem roda?

Infeliz comparação, não se dirige um carro sem volante, mas se faz grandes coisas sem lazy load, e tambem existe a critéria que pode ser usada no lugar da HQL. Pra ser irônico tem que no mínimo saber oque está falando.

criteria sim e algo inutil ao meu ver…

bobmoe:

é justamente o contrário: difícilmente se faz grandes coisas sem Lazy Load
não da pra complicar a vida da maioria, só pq a excessão não usa isso, entende? enquanto alguns indivíduos que não usam perdem, no geral o coletivo se beneficia.

Bom… como todos sabemos isso não é verdade. Lazy load como citado aqui no tópico já tem sua funcionalidade questinável.
E não é complicar a vida da maioria a não ser que seja complicado pra você adicionar um jar no projeto, oque não deve ser verdade pois só o hibernate já adiciona 464641327 jars…

Então, mais uma prova de que você tem no seu projeto coisas inúteis a você…

Olha oque eu achei…

http://www.guj.com.br/posts/list/15/37646.java#200301

É isso que eu digo!

E quem disse que eu uso criteria em meus projetos???
eu uso o hibernate mas não gosto de trabalhar com criteria… prefiro hql ou sql mesmo…

Então, mais uma prova de que você tem no seu projeto coisas inúteis a você…

Olha oque eu achei…

http://www.guj.com.br/posts/list/15/37646.java#200301

É isso que eu digo!

você está vendo um framework como uma aplicação; não é (é apenas uma parte dela)! da forma que você diz cada framework teria que ser uma plataforma de plugins (como equinox por exemplo). imagine três camadas, cada uma com uma platraforma dessas rodando… :shock:
o próprio eclipse já tentou implementar algo precido com isso com o OSGI e sabe o que aconteceu? as pessoas chegam até a comprar suites de plugins que privam elas de ficar baixando tudo que precisam.

luistiagos:

E quem disse que eu uso criteria em meus projetos???
eu uso o hibernate mas não gosto de trabalhar com criteria… prefiro hql ou sql mesmo…

Não disse que você usa, disse que você o tem… é a mesma coisa que ter uma placa de vídeo onbord queimada, não te serve pra nada, mas vc não pode tirar ela de lá…

Então, mais uma prova de que você tem no seu projeto coisas inúteis a você…

Olha oque eu achei…

http://www.guj.com.br/posts/list/15/37646.java#200301

É isso que eu digo!

Caramba, você fica reclamando que o hibernate vem com a API de criteria enquanto a nhaca da tua web app Java depende de um pacote que vem com 2 toolkits de GUI sendo um incrivelmente bloated. Reclama da coisa certa, pelo menos!

Então, mais uma prova de que você tem no seu projeto coisas inúteis a você…

Olha oque eu achei…

http://www.guj.com.br/posts/list/15/37646.java#200301

É isso que eu digo!

Caramba, você fica reclamando que o hibernate vem com a API de criteria enquanto a nhaca da tua web app Java depende de um pacote que vem com 2 toolkits de GUI sendo um incrivelmente bloated. Reclama da coisa certa, pelo menos!

Nossa… não viaja cara!!
Primeiro eu citei como exemplo, e sequer estou reclamando apenas sugerindo uma discussão!
Segundo nhaca da minha app web?? Doque você ta falando???
Terceiro, eu reclamo doque eu quiser, se eu quiser reclamar da sua arrogância e prepotencia eu reclamo. Liberdade de expressão! Não estou agredindo ninguem então tenho direito de falar!

Numa boa, esse fanatísmo já tá fazendo vocês parecerem patéticos!!

Existe uma falha de concepção de que quanto mais plugins e mais extensibilidade melhor. Não vejo assim, mais plugins e mais extensibilidade implica em mais configurações a lidar (alguém quer perder tempo com isso?) e em mais complexidade. Conheço o Struts 2 com seu sistema de plugins e interceptors, mas seus pontos de extensão são poucos.

O framework mais extensível que eu já vi foi JavaServer Faces, onde tudo é passível de customização, desde os componentes, até as rotinas que executam no meio do ciclo de vida, passando pela customização da expression language. Portanto, pela sua grande extensibilidade, poderiamos concluir que é o melhor framewok do mundo, certo? Não! JSF é difícil, possui várias coisas não-óbvias (o DataTable, por exemplo) e a extensibilidade, apesar de presente, é complicadíssima.

Um framework fácil com Convention over Configuration pode ser conflitante com um framework extensível. A própria natureza do framework é limitar o domínio de problemas que pode ser resolvido, forçando uma arquitetura que se acredita ser de qualidade. O que eu quero dizer com isso? O usuário quer que o framework faça o trabalho sujo, se o cara tiver que ficar preocupado com extensões, plugins e configurações, no que o framework estará ajudando?

Por curiosidade, fanatismo ao que? Por favor, substancie isso.

Leonardo3001, um framework extensivel não significa um que exige toneladas de configuração. O RoR é um bom exemplo disso, é possivel customizar uma enorme quantidade de aspectos dele para quem quiser, porém é opcional e adota uma série de convenções a respeito disso.

você trabalha com o que? digo, que tipo de softwares?

eu acho criteria algo MUIIIIIIIIIIITO útil

Mas RoR é muito mais customizável porque a própria linguagem abre brechas pra que isso seja feito, não é uma coisa que veio só do framework não. Escrever um “RoR” em Java puro é praticamente impossível.

O próprio modo de se “escrever” plugins pro Rails é diferente, você simplesmente bota a coisa lá e ele é levantado junto com a aplicação, você não “configura”, no máximo você habilita o plugin pra um dos seus objetos com um “acts_as_qualquer_coisa” e nessa hora o seu objeto se enche de métodos que o plugin implementou. Funciona? Claro, mas é mais “Ruby” do que “Rails” em si.

louds:

Por curiosidade, fanatismo ao que? Por favor, substancie isso.

Mas RoR é muito mais customizável porque a própria linguagem abre brechas pra que isso seja feito, não é uma coisa que veio só do framework não. Escrever um “RoR” em Java puro é praticamente impossível.

O próprio modo de se “escrever” plugins pro Rails é diferente, você simplesmente bota a coisa lá e ele é levantado junto com a aplicação, você não “configura”, no máximo você habilita o plugin pra um dos seus objetos com um “acts_as_qualquer_coisa” e nessa hora o seu objeto se enche de métodos que o plugin implementou. Funciona? Claro, mas é mais “Ruby” do que “Rails” em si.

Você tá confundindo a facilidade da semântica Ruby com a mecânica dos plugins do Rails. RoR facilita muito as coisas pois possui auto-discovery de plugins, o sistema quase que inteiro é configurado via convenções ou defaults. Isso é algo que está mudando no mundo Java a uns 2 anos, para sorte daqueles que desenvolvem com.

volnei:

louds:

Por curiosidade, fanatismo ao que? Por favor, substancie isso.

Você ainda pergunta?? Se eu fizer um tópico para falar de concatenar strings o assunto vai acabar chegando no hibernate… Deixem o hibernate de lado e olhem mais para o foco da discussão.

foi você mesmo que começou quando criou o tópico:

Então leia novamente…

Alguém fecha este tópico por favor. Não está mais sendo produtiva esta discussão !!!

criteira pode ser substituida por hqls… então temos 2 coisas que nos trazem o mesmo resultado: criteria e hql…
pra que usar criteira se pode usar hql ou sql mesmo?

agora gostaria de saber sobre esses phantom reads… fiquei curioso sobre isto… pq abrir uma transação para fazer uma consulta? o que são phantom reads???

luistiagos:

criteira pode ser substituida por hqls… então temos 2 coisas que nos trazem o mesmo resultado: criteria e hql…
pra que usar criteira se pode usar hql ou sql mesmo?

Eu acho que Criteria é mais… OO, compilável, concreto??
Não sei qual é o termo correto…

Compare:

String hql = "select p from Pessoa p where p.nome = :nome";
Query q = s.createQuery(hql);
q.setParameter("nome", "test");
return q.list();

versus:

Criteria c = s.createCriteria(Pessoa.class);
c.add(Expression.eq("nome", "test");
return c.list();

Olha só quanta String no primeiro código… Se tiver algum erro de sintaxe na hql continda da String o compilador não vai acusar e o auto-complete da IDE não vai te ajudar.

microfilo:

Criteria c = s.createCriteria(Pessoa.class);
c.add(Expression.eq("nome", "test");
return c.list();

Olha só quanta String no primeiro código… Se tiver algum erro de sintaxe na hql continda da String o compilador não vai acusar e o auto-complete da IDE não vai te ajudar.

O segundo exemplo mostra uma das falhas do Java, suporte incompleto a Metatypes literals. No lugar de "nome"o ideal seria utilizar o literal do atributo ou getter.