Você não gosta do Hibernate? Eu tb não! Leia para entender o porquê

Achei interessante suas suposições, agora vou dar algumas opiniões a favor do nosso amigo hibernate!!

Bom eu ja escrevi milhões de queries sql em tudo que é tipo de banco , me considerava pró em queries apesar de não ser DBA , sei a fundo como são executadas o que utiliza indice ou não , como ele executa e melhores soluções , não achei a migração pra uma api de query no caso criteria tão complexa assim ,até pq não sou fã do hql que é bem menos "orientado a objetos", tão diferente assim de falar "ESPANHOL PRA PORTUGUES" e isso aqui "E nem pense em tentar falar em português comigo!" só utilizar native queries…voce vai falar o portugues com o seu banco. Até pq o hql deixa de ser uma simples "query" e vira uma "query orientada a objeto" o que é totalmente diferente ela não navega apenas em suas tabelas mas tb nos seus relacionamento de classes…

Acho que esse ponto nem é discutivel a quantidade de código que se produz a mais indo pra um JDBC da vida.

Pensa se que ninguem se propõe a usar algo que não conhece sem ao menos ter o mínimo de bom senso e dar uma olhada na documentação , de como funciona o processo todo da coisa. Eu particularmente não gosto de usar xml pra configurar prefiro bem mais anotação e não vejo nenhuma zona nisso ate pq suas anotação não atravessam sua camada de modelo. Quanto a configuração programática , eu acho muito mais complexo , alias nunca gostei , ficar dando set pra cá set prá lá e dalhe java doc pra saber o que cada coisa faz no fim o esforço foi igual pra ambas as coisas. Tanto annotation quanto programaticamente.

Esse argumento de trocar banco de dados pra mim tb não cola , nunca colou , não existe empresa que se arrisque a esse nível. Assim como é o mesmo argumento de estar usando o hibernate e falar … "Pô esse hibernate ta legal mas vou mudar pra ibatis pra ver se melhora", quando se define uma tecnologia ou framework a ser utilizada dificilmente se troca , a não ser que o projeto seja refeito em sua maior parte e seja provado que a nova tecnologia vai resolver os problemas de vez.

Agora vamos aos trechos de código

Hibernate

@Entity
	public class User {

                @Enumerated
		public static enum Status {
			BASIC, PREMIUM, GOLD
		}

                @Id
                @GeneratedValue
		private int id;
		private String username;
		private Date birthdate;
		private Status status = Status.BASIC;
		private boolean deleted;
		private Date insertTime;
                .
                .
		
	}

Legal acoplei meu código a javax.persistence , ou seja tenho que carregar essa jar pra tudo que é canto . Bem vindo ao mundo das anotações.

BeanConfig config = new BeanConfig(User.class, "Users");
		config.pk("id", DBTypes.AUTOINCREMENT);
		config.field("username", DBTypes.STRING);
		config.field("birthdate", "bd", DBTypes.DATE); // note that the database column name is different
		config.field("status", new EnumValueType(User.Status.class));
		config.field("deleted", DBTypes.BOOLEANINT);
		config.field("insertTime", "insert_time", DBTypes.TIMESTAMP).defaultToNow("insertTime");

Pô mais acabei de falar qual meu tipo de dado …tenho que falar de novo ??? Multiplique esse trabalho x 50 entidades e seus relacionamento …alem do que tem o problema de não ser o lado esquerdo typesafe … coisa que o hibernate ao fazer query peca tb por enquanto…ate pq ja tem solução pra isso…MetaModel generator…apesar deu achar que isso deveria ser nativo da api.

BeanManager beanManager = new BeanManager();
			BeanConfig userConfig = getUserBeanConfig();
			BeanConfig postConfig = getPostBeanConfig();
			beanManager.addBeanConfig(userConfig);
			beanManager.addBeanConfig(postConfig);

			conn = getConnection();
			JdbcBeanSession session = new H2BeanSession(beanManager, conn);

			createTables(conn);

			User u = new User("saoj", "1980-01-02");
			session.insert(u);

			Assert.assertEquals(1, u.getId());

			// Now insert a post for this user...
			Post p = new Post(1, "Test", "This is a test!");
			session.insert(p);

			Assert.assertEquals(1, p.getId());

			// Load from the database...
			p = new Post(1);
			boolean loaded = session.load(p);
			Assert.assertEquals("Test", p.getTitle());
			Assert.assertEquals(1, p.getUserId());
			Assert.assertNull(p.getUser()); // you did NOT load any user from the database here... (we like manual lazy loading, not automatic lazy loading!)

			// Load user for this post... (let's do our manual lazy loading)
			u = new User(p.getUserId());
			loaded = session.load(u);
			Assert.assertEquals(true, loaded);
			p.setUser(u); // manual lazy loading (forget about automatic lazy loading, you want control!)

			// Use JOIN to load all dependencies with a single query... (you know how to make a join, right?)

			p = new Post(1);

			StringBuilder query = new StringBuilder(256);
			query.append("select ");
			query.append(session.buildSelect(Post.class, "p"));
			query.append(", ");
			query.append(session.buildSelect(User.class, "u"));
			query.append(" from Posts p join Users u on p.user_id = u.id");
			query.append(" where p.id = ?");

			stmt = conn.prepareStatement(query.toString());
			stmt.setInt(1, p.getId());

			rset = stmt.executeQuery();

			if (rset.next()) {

				session.populateBean(rset, p, "p");

				u = new User();

				session.populateBean(rset, u, "u");

				p.setUser(u); // manual lazy loading (we prefer to have control!)
			}

			Assert.assertEquals(1, p.getId());
			Assert.assertEquals("Test", p.getTitle());
			Assert.assertEquals(1, u.getId());
			Assert.assertEquals("saoj", p.getUser().getUsername());
			Assert.assertTrue((new Date()).getTime() >= p.getInsertTime().getTime());

			rset.close();
			stmt.close();

			// Deleting => No cascade deletes, if you want that implement in the database level...

			u = new User(1);
			boolean deleted = session.delete(u);
			Assert.assertEquals(true, deleted);

			// Post of course is still there...
			p = new Post(1);
			loaded = session.load(p);
			Assert.assertEquals(true, loaded);
			Assert.assertEquals(1, p.getUserId()); // of course this user is gone!

			u = new User(1);
			loaded = session.load(u);
			Assert.assertEquals(false, loaded); // use was deleted above...

Quanto ao resto recaimos quase na mesma quantidade de código e nos mesmos nomes … tirando que isso …

StringBuilder query = new StringBuilder(256);
			query.append("select ");
			query.append(session.buildSelect(Post.class, "p"));
			query.append(", ");
			query.append(session.buildSelect(User.class, "u"));
			query.append(" from Posts p join Users u on p.user_id = u.id");
			query.append(" where p.id = ?");

			stmt = conn.prepareStatement(query.toString());
			stmt.setInt(1, p.getId());

			rset = stmt.executeQuery();

			if (rset.next()) {

				session.populateBean(rset, p, "p");

				u = new User();

				session.populateBean(rset, u, "u");

				p.setUser(u); // manual lazy loading (we prefer to have control!)
			}

é muito maior e complexo que isso ;

Criteria criteria = session.createCriteria(Post.class);
criteria.createCriteria("user",Criteria.INNER_JOIN);
criteria.add(Restrictions.eq("id",id));
List<Post> posts = criteria.list();
for(Post post:posts){
       System.out.println(post);
}

Ps : Não revisei o código , to fazendo de cabeça aqui.

Esse é meu ponto de vista dos dois mundos apresentados , isso pq num foi falado de um monte de conceitos como auditoria,cache,validações,transações que o hibernate tem ferramentas prontas ja quase que embutidas com ele pra melhorar a produtividade.

Ha mais de 1 ano nem trabalho com banco relacional mais ,só com cloud agora, e chega uma hora que ate isso voce para de perder o foco em mapeamento etcetc e tem que voltar aos conceitos basicos de banco de dados onde não existe de novo lazy loading , etc…

Sinceramente… prefiro colocar Annotations do que fazer todas aquelas coisas programáticas. Sei SQL, JOIN e blá blá blá, mas ainda prefiro o Hibernate.
E quanto a ser raro trocar de banco de dados… é raro, mas não é impossível. Ainda prefiro portabilidade, também.

Olha, gosto é gosto e não se discute!

Mas teus argumentos são inválidos. Na verdade, o seu mapeamento programático, não tem nada haver com o que o Fowler falou! O que ele disse é que usar arquivos de configuração nem sempre faz sentido, e fazer a configuração via código pode ser a melhor opção.

O que você está fazendo ali é trocar uma ferramenta ORM por outra. Eu aindo prefiro o JPA e anotações. A meu ver essa forma da mais trabalho além do que o MentaBean só se aplicar a casos simples:

1. Qual a diferença do MentaBean para o Hibernate?

R: O MentaBean, assim como o Hibernate e o iBatis, é um framework de ORM, ou seja, de mapeamento de objetos Java para tabelas de um banco-de-dados relacional. A diferença é que o MentaBean foca apenas nas questões simples de qualquer framework ORM, ou seja, CRUD (Create, Read, Update, Delete) de beans, load, add e remove de relacionamentos e carregamento de listas de beans com suporte a sorting e limit. O MentaBean não trata por exemplo de situações mais avançadas que o Hibernate trata como remoção em cascata, lazy-loading automático, locks, herança, etc. Na verdade o MentaBean está mais para um gerador automatizado de queries SQL (como o iBatis) do que para um framework completo de ORM (como o Hibernate).

Mesmo para aplicações simples eu usaria o Hibernate, pois um sisteminha tente a se tornar um “sistemão” e isso facilita a evolução natural do projeto.

Claro que hibernate não é bala de prata, existem alguns casos em que ele não é melhor opção, mas esses casos são raros e é facilmente contornável fazendo o mapemanto na mão.

A utilização do MentaBean não invalida o uso de DAOs também. O DAO serve para fazer a separação de responsabilidade. Na verdade não é porque você usa hibernate que necessita usar DAO, você pode usar o padrão Active Record do Martin Fowler (http://martinfowler.com/eaaCatalog/activeRecord.html).

Realmente o Hibernate não é um framework simples, é bem complexo e para dominá-lo é necessário um bom estudo. Mas dizer que “Segundo esse heavyweight framework, banco-de-dados é algo muito complicado e precisa ser abstraído” é uma falácia. Se for assim o qualquer Framework ORM, inclusive o MentaBean, se propõe a isso. O que qualquer framework ORM se propõe é retirar essa tarefa do programador! Pra quem já leu o livro do Martin Fowler, Padrões de Arquitetura de Aplicações Corporativas, sabe disso. A finalidade de um framework ORM é justamente fazer com que o programador não se preocupe com a mapeamento objeto relacional, que se preocupe com o dominio da aplicação. O que é complicado e necessita ser abstraído é o Mapeamento Objeto Relacional e não o banco de dados (quem já fez isso, sabe bem o quão complicado pode ser)!

Não é por que se usa um framework ORM que não se deve conhecer SQL, bem pelo contrário.

saoj:

Banco-de-dados é algo bastante simples. Qualquer programador deveria se sentir confortável em trabalhar com SQL, índices, transações, cache, lazy loading, etc. Mas infelizmente não é isso que acontece. O tal do Hibernate virou PADRÃO de mercado. Segundo esse heavyweight framework, banco-de-dados é algo muito complicado e precisa ser abstraído. Então o que ele propõe? Sai SQL e entra HQL ou Criteria. Transações, cache, lazy loading, pode esquecer. Isso vai acontecer via mágica. E se algo não sair como esperado? Aí se vira amigo! Como vc pode ser tão burro de não configurar aquelas anotações direito? É o que eu chamo de trocar uma complexidade por outra maior/pior, com pouquíssimas vantagens.

Essa vai pro meu professor de banco de dados que já faz 2 bimestres que esta falando(enchendo lingüiça na verdade) sobre Hibernate, logo eu que estava tão entusiasmado com a possibilidade de escrever algo em PL/SQL …(desculpa ai o momento desabafo ).

Em nome dos ditos ‘padrões de mercado’ é deixado de lado o estudo mais profundo do funcionamento de um banco de dados por essa gambiarra (bem feita …mas não deixa de ser uma gambiarra).

Enfim … excelente texto.

x@ndy:

Olha, gosto é gosto e não se discute!

Mas teus argumentos são inválidos. Na verdade, o seu mapeamento programático, não tem nada haver com o que o Fowler falou! O que ele disse é que usar arquivos de configuração nem sempre faz sentido, e fazer a configuração via código pode ser a melhor opção.

O que você está fazendo ali é trocar uma ferramenta ORM por outra. Eu aindo prefiro o JPA e anotações. A meu ver essa forma da mais trabalho além do que o MentaBean só se aplicar a casos simples:

Concordo completamente!

E, também, se fosse ruim, não seria especificação JPA ;]

Gosto de usar JDBC puro, acredito por eu ser um DBA.

Não ach complicado usar JDBC puro junto com um DAO.

Prefiro minha aplicação rodando sem algo “desnecessário” que pese no desempenho final da aplicação.

Hoje em dia o pessoal prefere menos trabalho, mesmo que isto signifique uma certa qualidade menor no final.

Pessoal prefere usar anotações simples. por que você não precisa perder mais tempo fazendo um DAO completo via JDBC e não pensa e fica cego para as desavantagens…

São dois caminhos diferentes:

:arrow: ou vc decide aprender e entender o Hibernate, com todas as sua complexidades e mágica e fazer todas as suas queries com HQL e Criteria (não faz sentido usar SQL com Hibernate).

:arrow: ou vc conclui que banco-de-dados não é um bicho de sete cabeças e vai de SQL + JDBC + MentaBean (ou iBatis).

A vantagem da última opção é que você vai estar no controle e vai saber exatamente o que acontece e quando. E mais linhas de código não é necessariamente pior. E essas linhas estarão abstraídas dentro dos seus DAOs, assim como o código do Hibernate estaria.

Se o cara não sabe SQL, não sabe banco de dados, nunca escreveu um DAO, Hibernate será uma grande pedida. O meu ponto é que para o cara que sabe essas coisas e se sente confortável em falar diretamente com o banco-de-dados, precisa fazer queries complexas, etc. usar Hibernate é um grande contra-senso. É trazer para o seu projeto uma complexidade desnecessária através de um framework heavyweight. A linguagem que todos os banco-de-dados entendem é SQL, então seria legal utilizar essa linguagem.

E mais uma coisa: veja como a abstração feita pelo Hibernate cai na questão de “trocar uma complexidade por outra maior/pior”. Para constatar isso veja quantas perguntas e problemas relacionados ao Hibernate há aqui no GUJ. De simples, e rápido não tem absolutamente nada. O meu ponto é que as pessoas não deveriam ser obrigados a usá-lo, principalmente se entendem de banco-de-dados. Abstração só é bem-vinda quando ela consegue abstrair reduzindo drasticamente a complexidade sem comprometer a flexibilidade. Se não o Maker seria e a melhor coisa do mundo.

Gosto dos tópicos do saoj, porque mesmo não concordando algumas vezes com o que ele diz, ele induz a um debate saudável sobre coisas interessantes.

Muito legal o tópico saoj, parabéns.

Eu, como não sou nenhum expert em BD achei excelentes os dois pontos de vista!
Estou dando uma estudada nos dois lados da moeda!
Essa discussão é muito mais produtiva que essas piadas que ficam postando no fórum!
Valeu!

Tópico interessante.

Entre escolher os primos pobres(Ibatis ou MentaBean), ou o primo rico(Hibernate), com toda certeza
iria de Hibernate, pois tem mais funcionalidades (remoção em cascata, lazy-loading automático, etc).
Mas isso é opinião pessoal, pois prefiro errar pelo excesso do que pela falta e ter que reinventar a roda.

Trabalho com JDBC puro e pelo o que percebi para quem ja tem um fonte legado com JDBC puro o MentaBean parece ser o mais fácil para se migrar entre o hibernate, iBatis e o próprio MentaBean.

Vi que possui download separado do MentaFramework aqui, mas este jar esta 100% com o estado do projeto? (já que ali marca que é um beta)

Jose111:

Trabalho com JDBC puro e pelo o que percebi para quem ja tem um fonte legado com JDBC puro o MentaBean parece ser o mais fácil para se migrar entre o hibernate, iBatis e o próprio MentaBean.

Vi que possui download separado do MentaFramework aqui, mas este jar esta 100% com o estado do projeto? (já que ali marca que é um beta)

O projeto agora é independente do Mentawai e pode ser baixado aqui: http://mentabean.soliveirajr.com/

Pra mim Criteria é o que há!

Tenho queries tão dinâmicas que possuem cerca de 20 ifs e dependendo do if que entra, ele ja faz o join com a tabela X, senão faz com a tabela Y e por ai vai, fazer isso com StringBuilder é um saco! isso é fato.

Mapeamento tanto com xml, annotation ou programático, é um ônus de inicio de projeto, eu mesmo só mexo em annotation hoje para adicionar mais um campo etc, e é coisa simples de se fazer.

Antes não usava JPA por não possuir Criteria, tinha que fazer gambiarras, mas com o JPA2 apesar das Criterias serem mais complicadas ao meu ver, ainda sim vejo vantagem.

Subqueries com Critéria é mão na roda.

Enfim, cada um tem um costume, cultura etc…

Você sempre dá a entender que quem usar Hibernate, é porque não sabe SQL puro, mexer com banco de dados, etc.

Já desenvolvi um projeto inteiro com JDBC puro (o que deu muito trabalho, gastei bastante tempo, etc.), depois tive que mudar de PostgreSQL para MySQL (deu mais trabalho ainda mudar todas as SQLs). Com Hibernate, qualquer mudança no mapeamento é muito mais simples.

Realmente tem perda de desempenho, se comparar com trabalhar diretamente com JDBC. Mas o cache do Hibernate já ajuda no desempenho…

Enfim, ainda não me convenceu a parar de usar Hibernate. E enquanto Hibernate é construído em cima de uma especificação, esses 2 ai não.

aqui usamos ibatis

Markus Alemao:

saoj:

Banco-de-dados é algo bastante simples. Qualquer programador deveria se sentir confortável em trabalhar com SQL, índices, transações, cache, lazy loading, etc. Mas infelizmente não é isso que acontece. O tal do Hibernate virou PADRÃO de mercado. Segundo esse heavyweight framework, banco-de-dados é algo muito complicado e precisa ser abstraído. Então o que ele propõe? Sai SQL e entra HQL ou Criteria. Transações, cache, lazy loading, pode esquecer. Isso vai acontecer via mágica. E se algo não sair como esperado? Aí se vira amigo! Como vc pode ser tão burro de não configurar aquelas anotações direito? É o que eu chamo de trocar uma complexidade por outra maior/pior, com pouquíssimas vantagens.

Essa vai pro meu professor de banco de dados que já faz 2 bimestres que esta falando(enchendo lingüiça na verdade) sobre Hibernate, logo eu que estava tão entusiasmado com a possibilidade de escrever algo em PL/SQL …(desculpa ai o momento desabafo ).

Em nome dos ditos ‘padrões de mercado’ é deixado de lado o estudo mais profundo do funcionamento de um banco de dados por essa gambiarra (bem feita …mas não deixa de ser uma gambiarra).

Enfim … excelente texto.

Eu uso DAOs para abstrair a camada de persistência. O mapeamento (seja via Ibatis, Hibernate ou MentaBean) só me ajuda a escrever os DAOs.

saoj:

x@andy:

Realmente o Hibernate não é um framework simples, é bem complexo e para dominá-lo é necessário um bom estudo. Mas dizer que “Segundo esse heavyweight framework, banco-de-dados é algo muito complicado e precisa ser abstraído” é uma falácia. Se for assim o qualquer Framework ORM, inclusive o MentaBean, se propõe a isso. O que qualquer framework ORM se propõe é retirar essa tarefa do programador! Pra quem já leu o livro do Martin Fowler, Padrões de Arquitetura de Aplicações Corporativas, sabe disso. A finalidade de um framework ORM é justamente fazer com que o programador não se preocupe com a mapeamento objeto relacional, que se preocupe com o dominio da aplicação. O que é complicado e necessita ser abstraído é o Mapeamento Objeto Relacional e não o banco de dados (quem já fez isso, sabe bem o quão complicado pode ser)!

Não é por que se usa um framework ORM que não se deve conhecer SQL, bem pelo contrário.

São dois caminhos diferentes:

:arrow: ou vc decide aprender e entender o Hibernate, com todas as sua complexidades e mágica e fazer todas as suas queries com HQL e Criteria (não faz sentido usar SQL com Hibernate).

:arrow: ou vc conclui que banco-de-dados não é um bicho de sete cabeças e vai de SQL + JDBC + MentaBean (ou iBatis).

A vantagem da última opção é que você vai estar no controle e vai saber exatamente o que acontece e quando. E mais linhas de código não é necessariamente pior. E essas linhas estarão abstraídas dentro dos seus DAOs, assim como o código do Hibernate estaria.

Se o cara não sabe SQL, não sabe banco de dados, nunca escreveu um DAO, Hibernate será uma grande pedida. O meu ponto é que para o cara que sabe essas coisas e se sente confortável em falar diretamente com o banco-de-dados, precisa fazer queries complexas, etc. usar Hibernate é um grande contra-senso. É trazer para o seu projeto uma complexidade desnecessária através de um framework heavyweight. A linguagem que todos os banco-de-dados entendem é SQL, então seria legal utilizar essa linguagem.

E mais uma coisa: veja como a abstração feita pelo Hibernate cai na questão de “trocar uma complexidade por outra maior/pior”. Para constatar isso veja quantas perguntas e problemas relacionados ao Hibernate há aqui no GUJ. De simples, e rápido não tem absolutamente nada. O meu ponto é que as pessoas não deveriam ser obrigados a usá-lo, principalmente se entendem de banco-de-dados. Abstração só é bem-vinda quando ela consegue abstrair reduzindo drasticamente a complexidade sem comprometer a flexibilidade. Se não o Maker seria e a melhor coisa do mundo.

Olha, você continua usando de falácias ao dizer que hibernate faz mágica e que com ele não é necessário conhecer o banco de dados.
Como não conhecer o banco de dados se muitas vezes é necessário entender como uma consulta criada pelo se framework ORM favorito (Seja o Hibernate, MentaBeans, IBatis, etc) está lenta e é necessário otimiza-la?
O uso de um framework ORM não substitui o conhecimento do banco de dados, pois ainda é necessário criar as tabelas, índices, storeds procedures, etc! O conhecimento de um não invalida o conhecimento do outro. Conhecimento de banco de dados não se limita ao conhecimento de DQL.

Como disse antes, gosto é gosto e não se discute.

Mas o impacto de usar um framework ORM mais simples, como MentaBeans, em conjunto com JDBC, se da em aplicações complexas, com relacionamentos complexos entre classes.
O MentaBeans é bom para simples CRUD, mas uma aplicação complexa não é feito de simples CRUD. Então você pode usar JDBC para os casos mais complexos, como para mapear herança. Mas ai você está fazendo uma gambia para resolver um problema que deveria ser feito pelo seu ORM! Você não está usando a ferramenta certa para o problema certo.

O problema da utilização do JDBC do modo tradicional é a replicação de código entre diversas classes. A adição de um campo novo no banco cria um problema, pois diversas consultas devem ser alteradas, e como saber onde tudo deve ser alterado? Eu já tive esses problemas milhares de vezes em sistema com interface inteligente. Ai entra a programação orientada a objetos. Só que isso não resolve o problema, você pode criar um Active Record, só que você continuará tendo código replicado. Você então começa a buscar padrões e criar objetos especializados para realizar suas consultas, inserções, etc. A cada passo você se desvia mais do seu problema original que é o domínio da sua aplicação para fazer o mapeamento objeto relacional. O desenvolvimento do sistema se torna um exercício para criar um ORM!

Não que isso invalide o uso de um framework mais simples. Se você tem uma aplicação simples que faz uso direto de CRUDs e pouquíssimos casos complexos pode ser uma boa.
O uso de JDBC em uma aplicação muito simples também é válido. Na verdade o problema está em resolver o problema certo com a ferramenta certa. Usando as palavras do Martin Fowler:

Embora possamos identificar as três camadas usuais, apresentação,domínio e fonte de dados, em cada aplicação corporativa, a maneira simples para extrair dados de um único banco de dados e exibi-lo na Web pode, todo ele, consistir de um único procedimento. Eu ainda me esforçaria para separar as três camadas, mas, neste caso, poderia fazê-lo simplesmente colocando o comportamento de cada camada em sub-rotinas separadas. Se o sistema se tornasse mais complexo, quebraria as três camadas em classes separadas. Se a complexidade aumenta-se ainda mais, dividira as classes em pacotes separados

Seus comentários, são depreciativos em relação ao Hibernate e isso não está certo. Se em seus sistemas ele não se faz necessário ótimo para você, mas o mundo não é feito só das só dos seus sistemas!

saoj:

x@ndy:

Chamar o JPA/Hibernate de gambiarra é não conhecer a importância do Mapeamento Objeto Relacional. Na verdade é não conhecer OOP. Pois se você programa orientado o objeto e não usar uma ferramenta ORM se torna praticamente impossível, pois você acaba se desviando do domínio da aplicação para desenvolver o mapeamento.

Eu uso DAOs para abstrair a camada de persistência. O mapeamento (seja via Ibatis, Hibernate ou MentaBean) só me ajuda a escrever os DAOs.

A meu está faltando um conhecimento em padrões para você! Não é por que você usa um framework que necessita usar um DAO. Você pode usar um Active Record. Assim como pode usar JDBC para fazer o mesmo.

Você sabe para que serve um DAO? Para a coisa mais óbvia da orientação a objetos, a separação de responsabilidades! Quando você está criando um DAO está passando a responsabilidade pela persistência para outro objeto. Então você compõe sua entidade com seu DAO, fazendo com ele se torne um Repository. Utlizando um DAO, você não precisa se preocupar como seus dados serão persistidos se concentrando no dominio da aplicação.

Não precisa fazer absolutamente nada. Basta adicionar o campo no seu mapeamento. Acho que isso tanto o iBatis, Hiberante e MentaBean são iguais.

Eu vejo o Hibernate como o Maven. Para o corriqueiro ele vai resolver muito bem, mas para qualquer outra coisa mais complexa você vai ficar na mão a não ser que vc conheca o Hibernate tanto quanto o Gavin King.

Não tenho obrigacão de saber escrever um left outer join agrupado com somatório, ordenado, limitado, paginado e otimizado pelos indices certos usando HQL/Criteria junto com aquelas configuracões de relacionamento malucas. Agora em SQL eu não tenho desculpa. Para coisas complexas o melhor é vc assumir o controle ao invés de torcer para que a mágica funcione, e PL/SQL é a maneira mais natural para isso.

saoj:

O problema da utilização do JDBC do modo tradicional é a replicação de código entre diversas classes. A adição de um campo novo no banco cria um problema, pois diversas consultas devem ser alteradas, e como saber onde tudo deve ser alterado?

Não precisa fazer absolutamente nada. Basta adicionar o campo no seu mapeamento. Acho que isso tanto o iBatis, Hiberante e MentaBean são iguais.

saoj:

Eu vejo o Hibernate como o Maven. Para o corriqueiro ele vai resolver muito bem, mas para qualquer outra coisa mais complexa você vai ficar na mão a não ser que vc conheca o Hibernate tanto quanto o Gavin King.

Não tenho obrigacão de saber escrever um left outer join agrupado com somatório, ordenado, limitado, paginado e otimizado pelos indices certos usando HQL ou Criteria. Agora em SQL eu não tenho desculpa. Para coisas complexas o melhor é vc assumir o controle ao invés de torcer para que a mágica funcione, e PL/SQL é a maneira mais natural para isso.

Agora o mais importante no seu argumento:

saoj:

Não tenho obrigacão de saber escrever um left outer join agrupado com somatório, ordenado, limitado, paginado e otimizado pelos indices certos usando HQL ou Criteria.Agora em SQL eu não tenho desculpa

Em uma área em que a mudança é a única certeza isso é um grave problema. Vejo isso na mudança de paradigmas de programação, na adoção de testes, na adoção de práticas ágeis. As pessoas não querem mudar. Elas não querem apreender algo novo. Então se protegem criando falácias para a maioria das novas ideias e ferramentas apresentadas.

acho que a grande maioria aqui que esta defendendo o Hibernate se deve ao seguinte fato:

Maioria não sabe fazer com JDBC o que se faz com hibernate. o hibernate ele facilita a maioria das coisas, principalmente tempo, trabalho e etc

então o pessoal esta se justificando o por que não utiliza o hibernate mesmo que isto custe o desempenho final da aplicação.

Discordo.

Eu gostaria muito de estudar e aprender: Click, Cocoon, Struts, Tapestry, Wicket, AppFuse, Aranea, Context Framework, Eclipse RAP, FormEngine, Google Web Toolkit, Hamlets, IceFaces, ItsNat, JavaServer Faces, JBoss Seam, Jspx-bay, JVx WebUI, ManyDesigns Portofino, OpenLaszlo, OpenXava, Oracle ADF, Play!, RIFE, Shale, Sling, SmartClient, Spring, Stripes, ThinWire, Vaadin, Wavemaker, WebObjects, ZK, ztemplates.

Mas não tenho tempo nem neurônio para isso. Não sou um savant.

Então nesse mundo onde você tem um milhão de maneiras de fazer a mesma coisa, você estará perdido se não tiver uma bússola. Conhece aquele ditado: “Para quem não sabe onde quer ir qualquer caminho serve!” ou “Não importa a velocidade que você sobe a escada quando ela está encostada na parede errada!” ?

Minha bússula, que não necessariamente tem que ser usada por outros, me diz que COMPLEXIDADE é EVIL. Qualquer pessoa mediana pode fazer qualquer coisa funcionar bem em programacão. A diferenca é como se faz. Se um cara pega o meu sistema e não entende, ou ele é muito fraco ou eu é que sou. E na grande maioria das vezes será a última opcão. O que mais tem por aí são sistemas que só o autor entende, que poderia ter 5 objetos mas tem 50, que poderia ter usado 3 frameworks mas utilizou 30. Menos é mais! Foi o que o cara do pequeno principe falou. (“Em tudo na vida a perfeição é finalmente atingida, não quando nada mais existe para acrescentar, mas quando não há mais nada para retirar.”)

Então deixando de lado a enrolacão e indo direto ao ponto da minha discordância:

Eu só dou um passo para aprender uma coisa nova em tecnologia se eu vejo que o passo é na direcão da SIMPLICIDADE, do low-level para o high-level. do KISS principle, da complexidade maior para a complexidade menor, do aumento de produtividade. Por isso que eu não tento aprender o Hibernate, pois a minha bússula não aponta para ele. Aponta para coisas lightweights e flexíveis, sem configuracões bizarras onde eu posso entender o grande e o pequeno e que eu tenha certeza que o cara que olhar vai entender.

O Hibernate de simples não tem nada. Digite no google ‘site:www.guj.com.br problemas hibernate’ e veja quantos problemas ele te retorna. Então o meu ponto inicial continua sendo. Se você já sabe SQL e JDBC, duas coisas bem simples, não há porque abracar a complexidade extra do Hibernate, a não ser que vc queira por um daqueles motivos que citei acima. Use iBatis ou MentaBean que são bem mais simples, intuitivos, flexíveis e não-intrusivos.

Ai você colocou uma questão interessante, é a sua bussola, o seu ponto de vista! Do seu ponto de vista não vale a pena entender. Mas é o seu ponto de vista.

Ai você está afirmando que é algo bizarro, mas como afirmar que algo é bizzaro quando não se conhece aquilo da afirmação. Você até pode dizer que “acha” que aquilo é bizarro, pois não entende como funciona, mas você está afirmando. Como você pode afirmar que algo é bizarro se não conhece a fundo? Eu não posso afirmar que algo que eu não entenda, ou não queira entender, seja bizarro, mas você afirma que o Hibernate faz “mágica”, que tira o controle das suas mãos. Como você pode afirmar isso se não entende o hibernate?

Você está atacando uma tecnologia que ampramente utilizada, por que sua bússola não aponta para ela, por você “acha” que não deve apreende-la, por que “acha” que exista um forma mais simples. Mas é o que você “acha”!
Minha bússola já aponta para outros caminhos. Ao contrário da sua que é guiada pela simplicidade a minha é guiada pela experiência. E a minha bússola indica que nem sempre o caminho mais fácil ou simples é o melhor. A adição de complexidade é inerente ao desenvolvimento de sistemas. Um sistema sempre começa de maneira simples como um “sisteminha”, mas com o tempo a complexidade vai aumentando. O sistema perde sua simplicidade e já não posso mais usar as mesmas ferramentas de antes. O “sisteminha” está virando um “sistemão” e a complexidade deste requer que você use as ferramentas apropriadas.

O problema é que você coloca o uso desses frameworks mais simples como a bolachinha mais recheada do pacote e isso não é verdade. Eles podem ser melhor para determinados casos, para CRUDs repetitivos. Mas quando o caldo entorna eles perdem seu valor. Quando a simplicidade do sistema morre não da para insitir no uso dessas ferramentas.

Verdade, não posso afirmar que o Hibernate é bizarro, até porque ele não é. O que eu disse que é bizarro são as configuracões:

Então re-afirmando: O que é bizarro, na minha opinião pessoal, é tentar resolver complexidade com configuracão. Por exemplo, relacionamentos entre objetos é algo complexo e inerente de qualquer sistema. Se vc tentar abstrair isso usando configuracão, vc apenas transfere complexidade do código para configuracão. Por que eu gosto de configuracao programática? Por que não deixa de ser código, não deixa de ser OO e sendo assim vc pode abstrair e simplificar as coisas ali. Mas como vc simplifica/abstrai/encapsula um XML? Como faz isso com annotations? O que é bizarro pra mim é o conceito de complexidade na configuracão. Lugar de complexidade é em código onde ela pode ser abstraída/refatorada/minimizada. Muito da mágica do Hibernate acontece via configuracão. Isso na minha opinião pessoal é um passo na direcão errada.

Entendo a sua argumentacão. Um sisteminha vira um sistemão, mas o que garante que ele vai ficar sob controle do ponto de vista da complexidade não é o Hibernate e suas 1001 maravilhas, mas sim uma FUNDACAO lightweight e simples. Se comeca pesado e complexo, não tem como simplificar depois. Roda um projeto no stack Java tradicional Hibernate + Spring e veja o bolo que ele levanta, veja o peso e a quantidade de log que ele gera, veja aquelas exceptions que pulam do meio do nada, fazendo coisas que vc nunca pediu para serem feitas, mas que agora vc vai ter que que se virar porque pelo menos vc está usando o PADRÃO do mercado.

Sempre que eu escuto a palavra PADRÃO e ESPECIFICACÃO fico preocupado. Me lembro de EJB, de JSF, etc. Padrão e Especificacão não são necessariamente bons, e quase nunca o são.

Se o banco possui toneladas de campos com nomes que precisam corresponder a algo mais legível no modelo, se o modelo tem muitas propriedades transient ou se os joins causam problemas, o hibernate apenas trouxe a tona essa complexidade através das anotações. não tem milagre. o hibernate apenas joga na cara dos programadores complexidade que ele está mapeando.

Mas as anotações e o mapeamento via xml (que pessoalmente eu não gosto, pois torna o mapeamento complexo) não tem nada haver com configuração!"

As anotações não são configurações! De modo algum! Basicamente a anotação representa uma tarefa que deve ser feita pelo compilador. Essa tarefa é programada!
Ao invés de eu fazer o mapeamento programaticamente, que é uma tarefa monótona e repetitiva eu programo isso e crio uma anotação. Ao ver essa anotação o compilador irá “substituir” o código pelo o que eu programei anteriormente. Isso vale também para o mapeamento via XML.
A meu ver isso é mais simples do que fazer na mão. Se a busca é pela simplicidade essa é a melhor opção

Discordo. Anotação é configuração, um pouco melhor que XML, mas continua sendo markup e metadata. De código de programação não tem nada. Você consegue fazer um IF ou um LOOP com uma anotação?

Seguindo essa lógica eu poderia dizer que Java é código Assembly. Só porque uma coisa mais tarde vira outra, não significa que ela seja essa outra coisa. Annotation não é código, pelo menos para quem usa. Se o compilador faz ela virar código depois, isso não tem nada haver com quem está usando as anotações. Vc vai continuar tendo que entender e configurar as anotações bem certinho se não um abraço!

O Hibernate te entrega ANNOTATIONS ou XML para configurar. Ele NÃO te entrega uma API/DSL para vc configurar. Se vc quiser fazer sua própria annotation para configurar qualquer coisa no Hibernate, vc vai ter que olhar o código fonte do framework para tentar entender como ele funciona. Há mais de 5 anos que eu procuro um exemplo/documentação de como configurar o Hibernate com configuração programática e nunca encontrei. Talvez até já tenha sido lançado recentemente, pois até o Spring se rendeu a configuração programática depois que começou a perder terreno para o Guice.

Se vc quer automatizar configuração programática via anotação, que tal fazer um método? Aí já caímos no gosto pessoal. Eu prefiro configuração programática e centralizada. Se vc quiser trocar a configuração anotada, como faz? Configuração separada, independente e centralizada é o que há, mas muitos vão continuar preferindo configuração espalhada e anotada. Mas o ponto não é esse, com o Hibernate vc não tem essa opção, pois vc não tem uma configuração baseado em código/DSL/API. Vc tem um conjunto de anotações que vc precisa aprender e domar para que a coisa funcione. Aguentei durante anos dezenas de requests, até dos membros do projeto Mentawai, para disponibilizar anotações, e a resposta sempre foi: nada contra quem quiser fornecer num jar/projeto separado anotações que configurem o framework. Podem até fornecer um jar que configure o framework via XML. O approach de configuração programática do framework suporta isso muito bem e é muito simples fazer isso. Mas de maneira nenhuma o framework vai suportar e estimular o uso de Annotations e XML. O approach é configuração programática, independente e separada (ou não) do jar do build principal. Fazendo isso bem feito qualquer um pode ter a liberdade de fazer o que quiser depois. Eu respondo dúvidas sobre configuração programática, nunca sobre XML, Annotations, JSON, TXT, etc.

saoj:

x@ndy:

Mas as anotações e o mapeamento via xml (que pessoalmente eu não gosto, pois torna o mapeamento complexo) não tem nada haver com configuração!"

Discordo. Anotação é configuração, um pouco melhor que XML, mas continua sendo markup e metadata. De código de programação não tem nada. Você consegue fazer um IF ou um LOOP com uma anotação?

Seguindo essa lógica eu poderia dizer que Java é código Assembly. Só porque uma coisa mais tarde vira outra, não significa que ela seja essa outra coisa. Annotation não é código, pelo menos para quem usa. Se o compilador faz ela virar código depois, isso não tem nada haver com quem está usando as anotações. Vc vai continuar tendo que entender e configurar as anotações bem certinho se não um abraço!

O Hibernate te entrega ANNOTATIONS ou XML para configurar. Ele NÃO te entrega uma API/DSL para vc configurar. Se vc quiser fazer sua própria annotation para configurar qualquer coisa no Hibernate, vc vai ter que olhar o código fonte do framework para tentar entender como ele funciona. Há mais de 5 anos que eu procuro um exemplo/documentação de como configurar o Hibernate com configuração programática e nunca encontrei. Talvez até já tenha sido lançado recentemente, pois até o Spring se rendeu a configuração programática depois que começou a perder terreno para o Guice.

Se vc quer automatizar configuração programática via anotação, que tal fazer um método? Aí já caímos no gosto pessoal. Eu prefiro configuração programática e centralizada. Se vc quiser trocar a configuração anotada, como faz? Configuração separada, independente e centralizada é o que há, mas muitos vão continuar preferindo configuração espalhada e anotada. Mas o ponto não é esse, com o Hibernate vc não tem essa opção, pois vc não tem uma configuração baseado em código/DSL/API. Vc tem um conjunto de anotações que vc precisa aprender e domar para que a coisa funcione. Aguentei durante anos milhares de requests, até dos membros do projeto Mentawai, para disponibilizar anotações, e a resposta sempre foi: nada contra quem quiser fornecer num jar/projeto separado anotações que configurem o framework. Podem até fornecer um jar que configure o framework via XML. O approach de configuração programática do framework suporta isso muito bem e é muito simples fazer isso. Mas de maneira nenhuma o framework vai suportar e estimular o uso de Annotations e XML. O approach é configuração programática, independente e separada (ou não) do jar do build principal. Fazendo isso bem feito qualquer um pode ter a liberdade de fazer o que quiser depois. Eu respondo dúvidas sobre configuração programática, nunca sobre XML, Annotations, JSON, TXT, etc.

Para as pessoas que quiserem saber o que são anotações de uma lida em: http://download.oracle.com/javase/1,5.0/docs/guide/language/annotations.html. Ai verá que anotação não é configuração!

Cara, vc está muito emotivo e pouco racional. Anotação é muito diferente de configuração programática, mas parece que vc não quer aceitar isso. Ok, bola pra frente.

Olá,

Como dizia meu pai “Gosto e igual pescoço cada um tem um.”. Mas o objetivo da discussão é válido pois endendo que sempre devemos nos questionar sobre o caminho que tomamos e isso na nossa área se
refere a que tecnologia iremos usar para resolver um determinado problema.
Vou fazer algumas considerações sobre o que foi dito até o momento esperando que isso colabore com a discussão:

- Automatizar sem perder o controle
Entendo que para termos produtividade precisamos em certos momentos automatizar algumas atividades relacionados ao objeto da discussão(persistência). Programar tudo via código sem nenhuma
automação com certeza não será produtivo. O Hibernate nos propicia essa automação mas acaba de certa forma fazendo com que não tenhamos mais o controle do que está sendo executado. Por mais que
saibamos tudo sobre as configurações e HQL/Critéria (o que exige uma curva de aprendizado bem longa) nos deparamos constamente com problemas lançados pelo Hibernate e que não fazemos a mínima
idéia de como solucionar. Acabamos por vezes tendo que recorrer a depurar o código do Hibernate afim de descobrir o que está causando o problema(lentidão, exceptions que não informam claramente a
causa do problema, etc). Isso deixa de ser uma tarefa trivial e produtiva a partir do momento que por exemplo estamos numa fábrica de software onde o programador nem tem acesso a fazer esse
tipo de atividade e que com certeza essa atividade extra de debug acaba fazendo com que se leve mais tempo na produção final do sistema. Pra ficar mais claro minha colocação vou citar um exemplo
prático que passei no trabalho. Temos em nosso ERP muitas tabelas com milhões de registros e nos deparamos com problemas no sistema de NFe onde o Hibernate gera alguns SQL’s que realmente eu não
faria se fosse feito manualmente. Esses SQL’s colocados num plano de execução mostram a ineficiência de como foi montado. Gerando por vezes planos com FULL TABLE access para tabelas extremamente
grandes. Por mais que revisamos o modelo e configurações não conseguimos fazer nenhuma melhoria. Isso nos faz crer que realmente perdemos o controle. Talvez fosse ai o caso de escrever Native Query’s
do hibernate mas nesse caso começa o conflito entre performance x portabilidade. Quantas vezes já ouvimos discussões entre o DBA e o fornecedor do sistema com relação a lentidões provocadas
pelo SQL gerado pelo hibernate? Devemos concordar que com certeza o problema não é no banco, pois se não usamos os recursos que ele oferece como podemos exigir performance?

- Portabilidade[size=18] [/size]
Esse tema depende muito do objetivo a que se propõe o sistema desenvolvido. Se o alvo for clientes onde ele tem a opção de selecionar o banco de dados com certeza vamos precisar de
portabilidade. Em alguns momentos temos que sacrificar isso em função da performance, pois dificilmente vamos conseguir melhorias usando apenas o básico comum a todos os bancos.
O Hibernate assim como outros framework’s ORM vão propiciar portabilidade até o momento e que você precise assumir o controle e escrever coisas nativas/específicas para o banco em questão afim
de resolver problemas por exemplo de perfomance.

- Abandonar o que já aprendemos
Na nossa área em que no momento em que estou escrevendo este comentário tem milhares de pessoas criando mais tecnologias novas para que tenhamos que aprender seria um absurdo
jogar fora o conhecimento adquirido considerando que nem sempre o mercado nos dá o tempo suficiente para absorver novas tecnologias. Se pararmos para pensar em quanto tempo perdemos aprendendo o novo vamos
que isso se torna improdutivo. Por isso acredito que jogar fora o conhecimento de SQL que é justamente a linguagem mais difundida de banco de dados é como dar um tiro no pé. O ideal seria poder continuar usando o SQL
mas sem abdicar do novo. Poder usar SQL com OO. Pensando em termos de negócio se procurar alguém para ser contratado para nossa área veja quantos sabem SQL e quantos sabem HQL?
Acho que o novo deve ser testado e avaliado com certeza.

- Escolha da ferramenta/framework correto:
Já ouvi muito isso: “Usar um canhão para matar uma formiga.” A escolha depende muito do contexto do projeto. Depende se a empresa já usa uma tecnologia e não quer trocar. Se você tem a
abertura de testar e avaliar deve fazer isso com certeza. Não devemos ser muito religiosos a ponto de defender apenas uma ferramenta e não nos deixar avaliar outras.

- Configuração Programática x Configuração Annotation/XML
Não vejo diferença entre elas. As duas formas exigem que você aprenda ou sobre as anotações/XML ou sobre a API de configuração. Vejo apenas uma vantagem em configuração programática
em função de fazer com que suas classes de negócio sejam limpas e não dependam de tecnologia A ou B(classe de negócio com Annotation depende do jar das anotações). Com relação a desvantagem de
configuração programática existe o fato de que a cada nova mudança de configuração ela exige que o projeto seja recompilado e seja feito um novo redeploy.

- Troca de tecnologia as vezes é necessária
Com certeza a adoção de novas tecnologias em algum momento será necessária. Devemos trocar de tecnlogia apenas quando isso venha a trazer mais melhorias que possam resolver problemas
existentes ou que venha a nos acrescentar mais produtividade sem que com isso percamos o controle do que estamos fazendo. Já vi casos em fábricas de software em que a cada projeto novo se
adotava uma nova tecnlogia apenas como meio de aprendizado ou por modismo sem levar em consideração quanto tempo iria ser utilizada e quais os benefícios que ela irá trazer.
Não devemos nos fechar e simplesmente não aceitar que as coisas mudam. As vezes é preciso rever os conceitos.

- Clareza nas mensagens para o usuário do Framework
Quantas vezes já me deparei com framework’s ORM’s como o Hibernate que simplesmente nos lançam exceptions que não nos dizem onde está o problema. Quem aqui que nunca copiou e colou uma exception
do hibernate no google afim de descobrir o que significava que atire a primeira pedra. Enquanto isso deveria ser mais claro para o usuário do framework. Agora imagina se você não encontrou nada
sobre a exception no Google e ainda não tem os fontes do framework para fazer a indigesta tarefar de depurar para descobrir o que será que fez de errado. Ai como dizemos no trabalho: “Você tá na roça.”;

- Novas funcionalidades
Sejam bem vindas. Desde que não sejam impostas e que se possa optar por usar ou não. Funcionalidades no caso do Hibernate como deleção em cascata, lazy load, lock, etc não são de uso obrigatório. Por
isso se achaemos que perdemos o controle fazendo uso dessas funcionalidades basta não usá-las e fazer isso programaticamente sem automação. As funcionalidades que geram produtividade sem
perca do controle e que sejam intuitivas a ponto de nos dizer o que está dando errado quando ocorre algum problema sempre serão bem vindas.

- Complexidade X Flexibilidade
Que todo sistema começa simples e se torna complexo isso é o padrão. Pois sempre vão ser acrescentadas novas funcionalidades no sistema. Agora o que não pode é se tornar complexo e dificil de
manter. Isso ocorre também na escolha de um framework ORM. Quem é que não quer novas funcionalidades? O que ningúem deseja é que essas novas funcionalidades venham como dizem por ai a “engessar” o uso
fazendo com que se torne complexo e muito menos flexível.

- Cache
Essa é uma funcionalidade interessante em frameworks ORM como o Hibernate. Ela só deixa de ser interessante quando ouvimos dizer que o Hibernate não gerou o melhor SQL mas conseguiu suprir essa
deficiência usando um Cache. Isso no meu modo de ver é uma adequação ténica e não realmente uma melhoria como uma funcionalidade. A coisa complica mais um pouco quando se usa o cache de segundo nível.
Até parece a web, onde criou-se originalmente o HTML e desde então vem sendo feitas novas adequações técnicas(gambiarra) em camadas. Ex: html, jsp, asp, dhtml, xhtml, flash, applet, etc,etc. Talvez com HTML5
isso melhore.

Como todo mundo aqui disse o que pensava o no final querendo se esquivar disse “Isso é apenas minha opinião pessoal.”. Eu também não poderia deixar de dizer “Isso também é minha opinião pessoal”.

Vamos deixar aqui então um questionamento que acho que devemos fazer. Qual seriam então os requisitos ideias para o framework que tanto procuramos, que atenda gregos e troianos?

Fica aqui minhas sugestões ou necessidades para tal framework:

• Possibilidade de trabalhar com SQL e OO sem ter que aprender uma nova linguagem e abandonar o que já sabemos;
• Ter funcionalidades como delete cascade, lazy load, transações, lock, cache, etc sem criar mais complexidade;
• Permitir fazer select’s de objetos de forma parcial permitindo que o programador traga via SQL apenas os objetos que lhe interessam na árvore do objeto do principal Ex: trazer apenas nome da cidade no Objeto cidade de uma pessoa já que preciso apenas disso para apresentar na view. O Hibernate sempre vai trazer o objeto completo. Em muitos casos não precisamos dessa abordagem. O Objeto principal queremos de forma completa mas os relacionamentos normalmente precisamos mostrar apenas uma outra propriedade;
• Permtir configuração tanto via anotação/xml como programáticamente;
• Permitir que novas funcionalidades sejam opcionais e não impostas;
• Facilitar configuração dos relacionamentos. (Quem aqui que nunca se confundiu qual anotação usar OneToMany ou ManyToOne???
• Facilidade de Integração com outros frameworks como Spring, Guice, etc. Trazer exemplos disso ou ferramentas que façam isso;
• Ferramentas(plugins) que facilitem a criação de novos projetos usando o framework pois não temos obrigação de saber configurar tudo isso sozinho e nem advinhar como foi feito;
• Ferramentas(plugins) que permitam executar SQL’s e ver os objetos retornados e não o resultset. Permitindo navegar e inspecionar tais objetos sem ter que necessariamente
  fazer uma aplicação para isso. Quem aqui que nunca fez um HQL sem saber se o resultado seria o desejado e teve que executar várias a aplicação pra ver como isso comporta.
  (Hibernate tem HibernateTools que nos mostra os objetos mas não tem como ver as propriedades dos mesmos além de que diz que suporta querys nativas
  mas no plugin não permite usar sql e sim somente HQL e critéria). Talvez tenha query nativa somente para dizer que tem;
• Ferramentas(plugins) que permitam editar configurações de forma visual o que torna mais produtivo;
• Ferramentas(plugins) que permitam fazer engenharia reverso do banco com interação do usuário para resolver problemas como mapeamento de herança e não gerar o modelo simplesmente como tá no banco;
• Criar expressões para compor um SQL de forma que possamos por exemplo usar um nome de função igual pra todos os bancos e quando for executar trocar a expressão pela função nativa do banco.
  Permitindo com isso que tenhamos de certa forma uma maneira de melhorar a portabilidade. Isso também poderia se aplicar a sugestão de indices no sql o que melhora a performance mas que
  tem sintaxe diferente em bancos de dados diferentes. Fazendo com isso que consigamos melhorar a portabilidade e performance sem perder o controle;
• Ferramenta(plugin) que permita comparação entre o modelo OO e o banco e aponte as diferenças visualmente;
• Ferramenta(plugin) que permita edição SQL com auto complete de todos objetos do modelo de negócios;

Espero que possamos continuar a discussão e que vocês também possar colocar aqui o que esperam de um framework ideal para persistência.

:thumbup:

Edson Martins
Gerente de Tecnologia
A.J.Rorato
[email removido]

JDBC puro
very easy

Não é verdade. Vc está confundindo configuracão programática com Annotations. Configuracao programática é centralizada numa classe a parte. Ela é compilada a parte e pode ser distribuída a parte. Vc pode ter por exemplo o jar da aplicacao e dezenas de outros jars com configuracoes diferentes: config1.jar, config2.jar, etc.

Configuracao programática é a BASE. Com ela vc faz qualquer coisa que quiser. Vc transforma ela em que vc quiser. Não te agradou, abstrai. Cria métodos, loops, ifs, uma outra API por cima, automatiza, cria uma representacao em XML, JSON, TXT, HDF5, Annotations, properties, etc. Agora se um framework te dá um TXT para configurar relacionamentos vc terá problemas.

Se vc não quer ter que compilar sua configuracao (bobeira na minha opinião), vc pode usar Jython ou JRuby, importar as classes do Java e fazer a sua configuracao em Python ou Ruby.

Acho que essas coisas podem e devem ser controladas no nível da aplicacão, ao invés de no nível da configuracão e da mágica.

Delete cascade = vc cria uma transacao que deleta tudo o que vc precisa.

lazy loading = lazy loading tem que ser o padrão. E vc monta o seu objeto a medida que for precisando dele. Ou faz o seu DAO retornar tudo se quiser, o que é raramente necessário. O Hibernate oferece lazy loading automatíco, para que o programador não tenha que “se preocupar” com isso. Um tiro no pé na minha opinião. Muita mágica e o cara não sabe o que está acontecendo até ele tomar um LazyInitiationException. Discussão completa aqui: http://www.guj.com.br/java/57590-ser-lazy-preguicoso-ou-nao-ser

transacoes = isso não tem mistério nenhum, a não ser nos raríssimos casos de two-phase commit

lock = use o lock nativo do banco: select for update. Complicar isso pra quê?

cache = a aplicacão está em melhores condicoes de controlar isso, não o ORM tentar adivinar o que precisa de cache e o que não precisa. Vc pode usar um cache distribuído. Claro que o Hibernate também suporta Memcache, via mágica, annotations e AOP. Vc configura e passa a funcionar sabe-se lá deus como.

Bons comentários, Edson.

Nunca usei nem li a respeito do MentaBean, mas não duvido que seja bom, até gostei daquela configuração programática. O que eu não achei legal foi promovê-lo em cima de argumentos muitas vezes falaciosos a respeito do framework de persistência mais robusto do mercado. O Hibernate é um verdadeiro canhão, faz coisas que a gente nem sabe, então pra quê arrumar essa briga desnecessária? Não era mais fácil chegar e dizer “meu framework é tal e se propõe a resolver os problemas A, B e C”. O MentaBean não é nem nunca vai ser um substituto do Hibernate. Ele é apenas uma opção a mais.

fabiocsilva:

Nunca usei nem li a respeito do MentaBean, mas não duvido que seja bom, até gostei daquela configuração programática. O que eu não achei legal foi promovê-lo em cima de argumentos muitas vezes falaciosos a respeito do framework de persistência mais robusto do mercado. O Hibernate é um verdadeiro canhão, faz coisas que a gente nem sabe, então pra quê arrumar essa briga desnecessária? Não era mais fácil chegar e dizer, “meu framework é tal e se propõe a resolver os problemas A, B e C”. O MentaBean não é nem nunca vai ser um substituto do Hibernate. Ele é apenas uma opção a mais.

Não estou preocupado com o MentaBean. Esquece o MentaBean. Ele é um lixo. Nos lugares que eu falei MentaBean vc pode trocar por iBatis. Não sou louco nem quero competir com o Hibernate. Quero apenas defender o meu ponto de vista com argumentos. Se vc acha que os meus argumentos são falaciosos, fica a vontade para expor os seus.

O MentaBean e o iBatis pregam uma filosofia diferente do approach do Hibernate. Esse é o ponto da discussão, não framework A,B ou C.

Em tempo: Retirei a mencão ao MentaBean do meu ultimo post.

Isso eu concordo! Todas as discussões aqui deveriam ser baseadas em argumentos!

Att.

saoj:

fabiocsilva:

Nunca usei nem li a respeito do MentaBean, mas não duvido que seja bom, até gostei daquela configuração programática. O que eu não achei legal foi promovê-lo em cima de argumentos muitas vezes falaciosos a respeito do framework de persistência mais robusto do mercado. O Hibernate é um verdadeiro canhão, faz coisas que a gente nem sabe, então pra quê arrumar essa briga desnecessária? Não era mais fácil chegar e dizer, “meu framework é tal e se propõe a resolver os problemas A, B e C”. O MentaBean não é nem nunca vai ser um substituto do Hibernate. Ele é apenas uma opção a mais.

Não estou preocupado com o MentaBean. Esquece o MentaBean. Ele é um lixo. Nos lugares que eu falei MentaBean vc pode trocar por iBatis. Não sou louco nem quero competir com o Hibernate. Quero apenas defender o meu ponto de vista com argumentos. Se vc acha que os meus argumentos são falaciosos, fica a vontade para expor os seus.

Em tempo: Retirei a mencão ao MentaBean do meu ultimo post.

Bom, muito já foi dito aqui sobre o Hibernate, só vou dar alguns pitacos. A relação Robustez x Flexibilidade x Time to Market dele é excelente e muito maior do que o do iBatis e seus pares. Além disso, há a questão da comunidade, dos projetos paralelos como o Hibernate Validator, da documentação, enfim, tudo o que se espera de um framework maduro. No caso do iBatis, acredito que o principal problema que ele se propõe a resolver é a otimização das consultas. Tudo bem, as vezes o Hibernate não gera o código que escreveríamos usando sql puro. Mas você tem a opção de escrever SQL nativo se não concordar com a geração automática. Aliás você tem a opção de fazer tudo manualmente, à sua maneira. iBatis muitas vezes soa para mim como otimização prematura.

fabiocsilva:

saoj:

fabiocsilva:

Nunca usei nem li a respeito do MentaBean, mas não duvido que seja bom, até gostei daquela configuração programática. O que eu não achei legal foi promovê-lo em cima de argumentos muitas vezes falaciosos a respeito do framework de persistência mais robusto do mercado. O Hibernate é um verdadeiro canhão, faz coisas que a gente nem sabe, então pra quê arrumar essa briga desnecessária? Não era mais fácil chegar e dizer, “meu framework é tal e se propõe a resolver os problemas A, B e C”. O MentaBean não é nem nunca vai ser um substituto do Hibernate. Ele é apenas uma opção a mais.

Não estou preocupado com o MentaBean. Esquece o MentaBean. Ele é um lixo. Nos lugares que eu falei MentaBean vc pode trocar por iBatis. Não sou louco nem quero competir com o Hibernate. Quero apenas defender o meu ponto de vista com argumentos. Se vc acha que os meus argumentos são falaciosos, fica a vontade para expor os seus.

Em tempo: Retirei a mencão ao MentaBean do meu ultimo post.

Bom, muito já foi dito aqui sobre o Hibernate, só vou dar alguns pitacos. A relação Robustez x Flexibilidade x Time to Market dele é excelente e muito maior do que o do iBatis e seus pares. Além disso, há a questão da comunidade, dos projetos paralelos como o Hibernate Validator, da documentação, enfim, tudo o que se espera de um framework maduro. No caso do iBatis, acredito que o principal problema que ele se propõe a resolver é a otimização das consultas. Tudo bem, as vezes o Hibernate não gera o código que escreveríamos usando sql puro. Mas você tem a opção de escrever SQL nativo se não concordar com a geração automática. Aliás você tem a opção de fazer tudo manualmente, à sua maneira. iBatis muitas vezes soa para mim como otimização prematura.

Da forma como foi colocado aqui parece que o hibernate é lento, as anotações são ruins, HQL e Crirteria são monstros de sete cabeça e ele e só gera um monte de exceções. Mas isso são falácias. O Hibernate trabalha bem em 95% dos casos. O problema é justamente os 5% restantes, mas não existe ferramenta perfeita. O Hibernate não é bala de prata! Você vai trabalhar bem com ele durante muito tempo, mas em alguns casos você vai ter problemas, mas esses casos são raros! Nesses casos você faz como o fabiocsilva falou.

Gostar de mais de uma ferramenta do que outra não é o problema. O problema é atacar a outra ferramenta de forma falaciosa para promover a sua.

Se o Hibernate é tão ruim assim porque ele é tão utilizado? Por que as pessoas são obrigadas? Eu uso o hibernate/jpa e recomendo o seu uso e ninguém me obrigou a isso. Conheço outras programadores que fazem o mesmo e até agora não conheci ninguém que conhecesse e não gostasse. Então quem nos obrigou?
“Ah, as pessoas só usam porque é padrão de mercado”! Mas como ele se tornou um padrão? Sendo ruim é que não foi então sobra a opção que foi feita uma conspiração pelas grandes empresas para secretamente convencer os programadores que ele é bom, mesmo sendo ruim? Mas essas empresas estão interessadas no lucro, então porque vão promover uma tecnologia inferior? Dizer que o hibernate é ruim é uma falácia enorme. Não gostar como hibernate faz as coisas ai tudo bem, gosto não se discute mesmo.

Eu acho o hibernate mais produtivo do fazer o mapeamento programaticamente e quando ele não atende minhas necessidades eu utilizo outra ferramenta, ou faço o mapeamento a mão mesmo!

Essa discussão me lembra as que eu cansei de ouvir sobre linguagem de programação. Java é melhor que Delphi, Delphi é melhor que java. C é melhor que qualquer outra linguagem!
Eu programa nas 3 e sei que nenhuma delas é melhor que a outra. Uso cada uma conforme o que eu tenho que fazer! A ferramenta certa para o problema certo. E isso se aplica aos frameworks ORM!

Eu já coloquei os meus argumentos. Resumindo: Para o cara que sabe SQL e quer ter controle e flexibilidade o Hibernate é muita mágica, muito peso e muitos problemas sim.

Eu vou encerrar a discussão com o x@andy por aqui por que lendo as suas mensagens vejo que ele tem um amor muito grande pelo Hibernate e suas respostas estão pouco técnicas e muito emotivas.

Ok, mas há outros caminhos, há pessoas que pensam diferente, há o iBatis, há milhões de problemas e dúvidas diariamente sobre o Hibernate, etc.

Vc deveria ler mais Nelson Rodrigues: “Toda a unanimidade é burra!” E o Hibernate é uma unanimidade.

O problema não é o Hibernate, mas sim o que ele se preza a fazer. Acho que vc não sabe a diferença de eficiente para eficaz.

Esse tópico em nada vai mudar o fato de que Hibernate + Spring continuarão a ser o stack padrão do Java. Apenas vai abrir o olho das pessoas que as coisas podem ser feitas de maneira diferente.

Parabéns !!!

O MentaBean é um lixo. Esquece ele. Eu o fiz apenas para demonstrar o meu ponto de vista alternativo. Vc pode entender esse tópico como a diferença de approaches entre Hibernate e iBatis. Acho que isso vai te deixar mais tranquilo. Agora se as pessoas quiserem usar, é como vc falou. Cada um usa o que quizer e o que julgar melhor, não o que o mercado ou a unanimidade lhe empurrarem goela abaixo! Até porque quando o Hibernate surgiu a unanimidade e o padrão era EJB1 com EntityBeans.

Os argumentos foram apresentados, de maneira clara. Vc também apresentou os seus, na medida do possível. Agora cada um tira suas próprias conclusões e decide o que é falácia, o que é paixão e o que faz sentido.

Boa noite a todos,

Por mais divergentes que foram as opiniões o mais importante foi atingido que foi o fato de pararmos pra refletir sobre as tecnologias existentes. Parabéns aos que participaram e principalmente ao nosso amigo “saoj” que iniciou a discussão e nos fez refletir sobre tudo isso. Salvo as discusões mais acirradas onde cada um defendeu seu ponto de vista e que ninguém é obrigado a pensar de forma igual o resultado foi muito bom. O melhor framework não deve ser A ou B e sim consideramos que o melhor é o que dominamos, que sabemos usar e que nos propicia o melhor resultado para o projeto que estamos utilizando. Com certeza o Hibernate é um ótimo framework e senão o melhor, porém cabe a ressalva de que nem tudo é perfeito nessa vida. Não existe ainda esse mundo que queremos. E por mais que se faça num framework não será possível agradar a todos. Ainda bem que isso ocorre pois assim abre novas oportunidades para outros produtos. Talvez uma das falhas da discussão foi a forma como foi abordado o tema “Você não gosta do Hibernate?”, talvez desse ser “O que eu gostaria que o Hibernate fizesse e não faz” ou “O que vc acha deveria ser diferente no Hibernate?”. De tudo o que li algo me fez refletir sobre o que realmente é interessante e tevo um assunto que me chamou a atenção e que com certeza
estarei me aprofundando nos próximos dias “Configuração programática”. Com certeza vou poder tirar algo proveitoso dessa nova forma de pensamento que até então eu desconsiderei.

Espero que possamos nos encontrar em novos posts para discutirmos mais sobre outros assuntos.

Bom final de semana a todos,

Edson Martins

Cara, isso é um absurdo! Aonde eu disse que o hibernate é maravilhoso? Tu colocou como um comentário meu algo que eu não disse em lugar nenhum! É só ler os meus posts. O que eu disse é que gosto do hibernate, da mesma forma que você disse que não gosta. Eu não posso em cima do que você disse colocar um comentário seu assim, saoj: “Eu odeio o hibernate!”

Isso só demonstra que você se utiliza de falácias para desacreditar não só as ferramentas, mas as pessoas e promover seus argumentos. Eu usei argumentos técnicos suficientes e sempre disse que uma ferramenta não é melhor que outra. Eu disse que gosto é uma coisa que não se discute. Ai você inventa um comentário que eu não fiz e diz que meus comentários são passionais de modo a me desacreditar! Afinal quem está sendo passional?

Lamentável!

Foi uma ironia, por isso coloquei entre aspas. Mas do jeito passional que vc fala poderia muito bem ser verdade.

Não precisa ficar nervoso… Pessoal, o x@andy nunca disse que o Hibernate é maravilhoso. Isso foi conclusão precipitada minha. Ele deve achar o Hibernate razoável e só está aqui falando um monte de coisas sobre ele quer se divertir.

Podemos voltar a discussão técnica agora? Na verdade acho que melhor parar por aqui, se não alguém mais pode ficar nervoso. Eu realmente estava estranhando que esse tópico correu por quase 4 páginas sem ninguém entrar para atrapalhar.

Eu não falei que odeio o Hibernate, mas se vc tivesse concluído isso não seria mais do que um exercício primário de interpretação de texto e eu não teria ficado nervoso.

É muito difícil discutir com vc, porque vc é um cara muito esperto e eu não tenho capacidade de debater com vc num nível técnico. Então eu falo que vc acha o Hibernate maravilhoso para desacreditar vc. Tudo que eu falei aqui são falácias técnicas. O Hibernate á a melhor maneira de se trabalhar com Java e banco-de-dados. Como vc disse, dessa vez literalmente, o Hibernate trabalha bem em 95% dos casos e até agora vc não conheceu ninguém que não gostasse dele. Vc achou que eu fosse o primeiro herege que ia dizer que não gostava dele, mas me desculpe. Eu estava errado. O Hibernate é muito bom, eu é que não entendo das coisas direito. Vou estudar mais sobre ele. Obrigado pela sua ajuda!

saoj:

x@andy:

Um monte de coisas…

Foi uma ironia, por isso coloquei entre aspas. Mas do jeito passional que vc fala poderia muito bem ser verdade.

Não precisa ficar nervoso… Pessoal, o x@andy nunca disse que o Hibernate é maravilhoso. Isso foi conclusão precipitada minha. Ele deve achar o Hibernate razoável e só está aqui falando um monte de coisas sobre ele quer se divertir.

Podemos voltar a discussão técnica agora? Na verdade acho que melhor parar por aqui, se não alguém mais pode ficar nervoso. Eu realmente estava estranhando que esse tópico correu por quase 4 páginas sem ninguém entrar para atrapalhar.

Eu não falei que odeio o Hibernate, mas se vc tivesse concluído isso não seria mais do que um exercício primário de interpretação de texto, certo? Lastimável!

Que discussão técnica? Uma discussão técnica não deve ser constituído de falácias, ironias ou ataques aos membros do mesmo! Você ultrapassou a linha do debate técnico ao utilizar de falácias e ironizar meus comentários! E qual o propósito disso? Creio que seja me irritar, coisa que não estou, de modo que eu o ataque! Isso desviaria o foco do debate e me desacretitaria.
Errei ao pensar que você estava interessado em estabelecer um debate para discutir ideias e estabelecer posições, mas esse seu comportamento é típico de um Troll! E eu não alimento Trolls!

Repetindo pois acho que vc perdeu minha edição:

É muito difícil discutir com vc, porque vc é um cara muito esperto e eu não tenho capacidade de debater com vc num nível técnico. Então eu falo que vc acha o Hibernate maravilhoso para desacreditar vc. Tudo que eu falei aqui são falácias técnicas. O Hibernate á a melhor maneira de se trabalhar com Java e banco-de-dados. Como vc disse, dessa vez literalmente, o Hibernate trabalha bem em 95% dos casos e até agora vc não conheceu ninguém que não gostasse dele. Vc achou que eu fosse o primeiro herege que ia dizer que não gostava dele, mas me desculpe. Eu estava errado. O Hibernate é muito bom, eu é que não entendo das coisas direito. Vou estudar mais sobre ele. Obrigado pela sua ajuda!

Esse tópico está parecendo com aquelas discussões sobre o que é melhor,
utilizar como front controller somente simples Servlets ou usar algum framework mais parrudo com mais funcionalidades como Struts, JSF, etc.

Ibatis e Mentawai são bons, mais simples, com menos funcionalidades, mas são limitados em comparação com o Hibernate.
Em um projeto nem sempre temos tempo no cronograma para implementar coisas que tem no hibernate e que não existem nesses Ibatis e Mentabean.
Por isso é melhor utilizar algo já implementado, testado e garantido, sem precisar reinventar a roda toda hora.

x@ndy:

Markus Alemao:

saoj:

Banco-de-dados é algo bastante simples. Qualquer programador deveria se sentir confortável em trabalhar com SQL, índices, transações, cache, lazy loading, etc. Mas infelizmente não é isso que acontece. O tal do Hibernate virou PADRÃO de mercado. Segundo esse heavyweight framework, banco-de-dados é algo muito complicado e precisa ser abstraído. Então o que ele propõe? Sai SQL e entra HQL ou Criteria. Transações, cache, lazy loading, pode esquecer. Isso vai acontecer via mágica. E se algo não sair como esperado? Aí se vira amigo! Como vc pode ser tão burro de não configurar aquelas anotações direito? É o que eu chamo de trocar uma complexidade por outra maior/pior, com pouquíssimas vantagens.

Essa vai pro meu professor de banco de dados que já faz 2 bimestres que esta falando(enchendo lingüiça na verdade) sobre Hibernate, logo eu que estava tão entusiasmado com a possibilidade de escrever algo em PL/SQL …(desculpa ai o momento desabafo ).

Em nome dos ditos ‘padrões de mercado’ é deixado de lado o estudo mais profundo do funcionamento de um banco de dados por essa gambiarra (bem feita …mas não deixa de ser uma gambiarra).

Enfim … excelente texto.

Chamar o JPA/Hibernate de gambiarra é não conhecer a importância do Mapeamento Objeto Relacional. Na verdade é não conhecer OOP. Pois se você programa orientado o objeto e não usar uma ferramenta ORM se torna praticamente impossível, pois você acaba se desviando do domínio da aplicação para desenvolver o mapeamento.
Outra coisa, usar um framework ORM, não inválida a utilização de PL/SQL. O banco de dados continua existindo e pode ser necessário criar triggers e stored procedures. Algumas tarefas devem ser feitas no banco de dados e não no sistema, pois esse é muitas vezes mais eficientes. Fora a criação das próprias tabelas, índices ,etc.

Quanto a gambiarra:

Temos por uma lado bancos de dados, velhos, maduros,procedurais e consolidados. No outro nossas linguagens orientado a objetos (conceito ao qual rezamos todas as noites antes de dormir :D) são mundos distintos porem com certas semelhanças, dito isso, sempre fico com a impressão de que unir esses dois conceitos fica um certo cheiro estranho no ar(a dita gambiarra), indiferente se você usa ORM ou faz tudo na mão.

Quanto ao resto:

Sei que usar ORM não invalida a utilização de PL/SQL, porem o ponto que estava querendo abordar com minha colocação é que seria mais importante aprendermos sobre triggers e procedures do que um framework (alias ensinar framework é tipico de faculdade fraca) frameworks nascem e morrem mas conceitos ficam (no caso bancos de dados ficam).

Enfim a assunto já amornou, mas não tive tempo de responder antes (prova da matéria de banco de dados sobre Hibernate )

Humm… entendi sua colocação e você realmente tem razão, banco de dados relacioanais e objetos são coisas distintas realmente e a união dos dois é sempre problemática! O ideal seria utilizar um banco de dados OO ao invés de um relacional, mas eu pessoalmente nunca tive contato com um e nunca vi um sistema que fez uso de um. Só conheci casos em literatura, parece até algo fantástico e irrealizável.

Bom, se é uma cadeira de banco de dados, faz sentido realmente o aprendizado sobre os tópicos que você colocou. Mas se for uma cadeira de programação não!

saoj:

Banco-de-dados é algo bastante simples. Qualquer programador deveria se sentir confortável em trabalhar com SQL, índices, transações, cache, lazy loading, etc. Mas infelizmente não é isso que acontece. O tal do Hibernate virou PADRÃO de mercado. Segundo esse heavyweight framework, banco-de-dados é algo muito complicado e precisa ser abstraído. Então o que ele propõe? Sai SQL e entra HQL ou Criteria. Transações, cache, lazy loading, pode esquecer. Isso vai acontecer via mágica. E se algo não sair como esperado? Aí se vira amigo! Como vc pode ser tão burro de não configurar aquelas anotações direito? É o que eu chamo de trocar uma complexidade por outra maior/pior, com pouquíssimas vantagens.

Abaixo irei argumentar contra as vantagens oferecidas pelo Hibernate e apresentar uma alternativa muito mais simples e lightweight, para aqueles programadores que já ouviram falar em coisas "muito complexas" como um JOIN e um DAO.

bla, bla, bla…

Mano,

Não que eu defenda o Hibernate mais mto do que vc informou não condiz com a realidade o framework em questão.

Bom argumento.

PS: Obrigado por citar minha mensagem inicial de novo.

Fonte: http://stackoverflow.com/questions/825792/orm-yes-or-no

É impressionante como as pessoas não entendem que o Hibernate é o padrão do mercado e que eles deveriam estudá-lo mais para aprender como ele pode ajudar bastante o seu projeto. (Bom argumento!)

“I do recommend having some sort of abstraction to keep SQL out of your Java code, but that can be done simply with a DAO layer”. Esse cara não deve saber o que é um DAO.

Eu também pensava assim, mas depois que li a excelente explicação do x@andy sobre DAOs, aprendi que o Hibernate é muito importante, com ou sem DAO:

Falta conhecimento de padrões para esse cara do StackOverflow. Ele deveria estudar mais o Hibernate.

É muito difícil discutir com vc, porque vc é um cara muito esperto e eu não tenho capacidade de debater com vc num nível técnico. Então eu falo que vc acha o Hibernate maravilhoso para desacreditar vc. Tudo que eu falei aqui são falácias técnicas. O Hibernate á a melhor maneira de se trabalhar com Java e banco-de-dados. Como vc disse, dessa vez literalmente, o Hibernate trabalha bem em 95% dos casos e até agora vc não conheceu ninguém que não gostasse dele. Vc achou que eu fosse o primeiro herege que ia dizer que não gostava dele, mas me desculpe. Eu estava errado. O Hibernate é muito bom, eu é que não entendo das coisas direito. Vou estudar mais sobre ele. Obrigado pela sua ajuda!

• Tentando voltar ao tópico.

Então…este descontentamento em relação ao Hibernate e similares não é novidade, de vêz em quando surge alguem tentando construir um componente para aliviar essa…pressão vamos dizer assim. Exemplo: Persist https://github.com/rufiao/persist, existem outros mas não estou lembrando o nome no momento.

ORMs geram polemicas a todo momento, facilitam de um lado e complica do outro e gostando ou não o Hibernate é a solução mais interessante hoje, caso a opção seja adotar um ORM.

Na verdade o ponto é que o uso de banco de dados OO ainda não é uma realidade absoluta portanto qualquer coisas que seja utilizada para amenizar o impacto sempre irá dividir opiniões.

flws

Seu comentário foi muito bom. Concordo com tudo que vc falou. Existem vários como o MentaBean. Persist é um. jOOQ é outro. Não sei porque o pessoal insiste em prover alternativas ao Hibernate. Como falaram aí, deve ser preguica de aprender Hibernate.

Não conhecia o Persist. Parece ser bem legal. Uma coisa que eu noto e que me parece perigoso é o seguinte:

• O pessoal está viciado em achar que MENOS código é MELHOR. Deveriam então usar o Maker onde vc faz um sistema sem precisar escrever código nenhum. Isso é um erro na minha opinião. Se o cara quer realmente isso, então ele tem que ir programar em Ruby ou Python, que são linguagens bem mais expressivas. Por que estou falando isso? O persist tenta adivinhar o mapeamento de um objeto com o banco de dados:

// inserts a new customer (the class _Customer_ is mapped to the table _customer_ automatically)
 persist.insert(customer);

Ok, foram economizadas uma 10 linhas de código. Que maravilhoso não? Eu acho péssimo. Por que?

Eu prefiro ser EXPLICITO. Prefiro mapear o meu bean na mão e ter o controle. Se amanhã eu adiciono um novo campo no database ou uma nova propriedade no meu bean, não vou correr o risco de uma adivinhacão errada. Mesmo coisa se removo alguma coisa. Se a coisa foi mapeada explicitamente e eu removo do banco e esqueco de remover do meu mapeamento, vou ganhar um erro. Mas com essa adivinhacão nada acontece.

Então concluindo minha opinião: MENOS CÖDIGO NÃO Ë MELHOR. Não economize 10 linhas e faca o seu mapeamento na mão. A coisa fica clara, documentada e vc mantem o controle.

Programmatic Configuration:

BeanConfig config = new BeanConfig(User.class, "Users");
		config.pk("id", DBTypes.AUTOINCREMENT);
		config.field("username", DBTypes.STRING);
		config.field("birthdate", "bd", DBTypes.DATE); // note that the database column name is different
		config.field("status", new EnumValueType(User.Status.class));
		config.field("deleted", DBTypes.BOOLEANINT);
		config.field("insertTime", "insert_time", DBTypes.TIMESTAMP).defaultToNow("insertTime");

		beanManager.addBeanConfig(config);

Fluent API:

beanManager.bean(Post.class, "Posts")
			.pk("id", DBTypes.AUTOINCREMENT)
			.field("userId", "user_id", DBTypes.INTEGER)
			.field("title", DBTypes.STRING)
			.field("body", DBTypes.STRING)
			.field("insertTime", "insert_time", DBTypes.TIMESTAMP).defaultToNow("insertTime");

saoj:

fantomas:

…

EEntão concluindo minha opinião: MENOS CÖDIGO NÃO Ë MELHOR. Não economize 10 linhas e faca o seu mapeamento na mão. A coisa fica clara, documentada e vc mantem o controle.

Bem acredito que hibernate, JPA etc sejam a evolução da forma de persistir, concordo que há problemas, concordo que em alguns casos há perda de desempenho, mas devo lembrar que a agilidade, flexibilidade e adaptação ao paradigma O.O.
Um exemplo de evolução: iReport que gera todo o modelo de relatório de forma quase que automática em xml, bem particularmente não vou deixar de utiliza-lo só porque alguém disse que sou preguiçoso, considerando que vou economizar tempo, ganhar agilidade e etc. O mesmo posso dizer do netbens e até mesmo do Delphi. Esta é minha forma de analisar a situação, porém respeito a opinião de todos.

att.

…

Não estava falando do Hibernate, e sim da configuração automática do Persist. Preguiçoso talvez não tenha sido a palavra mais adequada. Não quiz depreciar ninguém, apenas dizer que economizar 10 linhas de código pode ser ruim e talvez seja melhor configurar o mapeamento explicitamente. Editei para “Então não economize 10 linhas e faça o seu mapeamento na mão”.

Já presenciei casos em que simplesmente abortaram o uso de hibernate pq 90% das pesquisas eram bem pesadas (necessitavam de uma Query bem especifica, muitas vezes até apelando pra funcoes do fabricante ex: Oracle CONNECT BY PRIOR), e o SQL gerado por ele nao atendia.

Só usar uma ‘native query’,não?

Só usar uma ‘native query’,não?

A independencia de banco de dados vai para o quiabo, se é que algúem deva ser preocupar com isso.

Só usar uma ‘native query’,não?

A independencia de banco de dados vai para o quiabo, se é que algúem deva ser preocupar com isso.

Nesse ponto eu concordo contigo,esse argumento da portabilidade é um daqueles que eu nunca vi(e nem conheço) ser usado na prática.

Mas queria levantar o seguinte ponto:Pq não tentar usar o melhor dos 2 mundos(deixar o Hibernate/JPA fazer bem o que ele sabe e resolver caso-a caso esses problemas pontuais?

Eu,por exemplo,gosto muito da facilidade que o Hibernate me proporciona(Anotattions,Api de Criteria,Projections etc) mas não hesito em deixá-lo de lado nos(poucos) casos onde ele mais me atrapalha do que ajuda.

Muitissimo legal suas considerações saoj.

É bom saber que existem outros que mesmo conhecendo as tecnologias vigentes e utilizadas pelo mercado é aberto a novas tecnologias.
É gente assim que abre caminho para a maioria de nós pequenos programadores.
Go ahead!!!
Todo mundo começa pequeno e enfrentando multidões.
Não é porque a maioria come coco (infelizmente come) que eu vou comer também não é?

http://www.guj.com.br/java/255094-hibernate-e-jpa-por-que
Como no caso do word da Microsoft de 100% do que ele pode fazer a maioria só utiliza 8%

A ideia de padronizar as ferramentas para ORM e exigi-las como criterio para avaliação de conhecimento é que não me soa muito interessante.
É direito de escolha de todo desenvolvedor decidir e opinar quais fundações são melhores para seus projetos.
Como eu disse no post acima, hibernete não é ruim, mas não dá pra me engessar nele.

Há vantagens e desvantagens, lógico.

Acho que o essencial é sempre buscar ter conhecimento de banco e ter BOM SENSO. Por exemplo, se a pessoa deixar as queries sendo exibidas no console e tiver o costume de acompanhá-las, mesmo que uma vez ou outra, pode otimizar suas consultas, fazendo queries específicas quando for o caso, evitando tráfego pesado e desnecessário.

É isso aí: Conhecimento + Bom senso.

cara vai procurar mulher… ave…

Só não gosto quando usam Hibernate como se fosse bala de prata. Hibernate é muito bom pra maioria dos casos, mas pra relatórios e consultas complexas uso SQL nativo, o próprio hibernate é aberto a isso através de named querys.

Pessoal, aproveitando o tópico.

Gostaria de pedir uma ajuda.

Eu trabalhava com desenvolvimento, usava Hibernate, mas já faz uns 4 anos e mudei de área. Na minha nova área, estou precisando fazer uma aplicação SIMPLES que necessita comunicar com um banco de dados já existente. Ou seja, não preciso e nem pretendo fazer nada muito complexo. Meu conhecimento anterior já está desatualizado e mais fraco.

Acredito que seja um pouco mais dificil de mapear do que quando o banco é gerado pelas anotações do Hibernate.

Quais dessas opcões vocês me aconselham a usar?
JDBC puro, Hibernate com SQL … etc…
Ou ainda é possível eu mapear o banco, sem te-lo que excluir e recriar e usar HQL.

Aguardo sugestões, muito obrigado.

danielnb:

Pessoal, aproveitando o tópico.

Gostaria de pedir uma ajuda.

Eu trabalhava com desenvolvimento, usava Hibernate, mas já faz uns 4 anos e mudei de área. Na minha nova área, estou precisando fazer uma aplicação SIMPLES que necessita comunicar com um banco de dados já existente. Ou seja, não preciso e nem pretendo fazer nada muito complexo. Meu conhecimento anterior já está desatualizado e mais fraco.

Acredito que seja um pouco mais dificil de mapear do que quando o banco é gerado pelas anotações do Hibernate.

Quais dessas opcões vocês me aconselham a usar?
JDBC puro, Hibernate com SQL … etc…
Ou ainda é possível eu mapear o banco, sem te-lo que excluir e recriar e usar HQL.

Aguardo sugestões, muito obrigado.

O sistema terá muitos CRUDs? Se tiver é vantagem usar Hibernate. E quando é um sistema que predomina consultas e relatórios, melhor SQL puro. Se for as duas coisas usa Hibernate e SQL através do próprio Hibernate quando necessário.

Considere também este artigo: http://blog.caelum.com.br/os-7-habitos-dos-desenvolvedores-hibernate-e-jpa-altamente-eficazes/

Muito obrigado javaflex.

É que eu estava meio preocupado em ter que estudar de novo, banco de dados para criar a sincronização com as Annotations do Hiber.
Então, veio a dúvida, se as vezes compensava usar SQL puro.

Porém, com o receio de que o banco possar crescer em tamanho e complexidade, acho que já vou deixar preparado para o Hibernate.

Muito obrigado pelas dicas.

A discussão é interessante, mas toda Framework tem sua vantagem e desvantagem.
O melhor mesmo é possuir um bom conhecimento em uma linguagem de programação, sendo ela também em banco de dados e usar desse conhecimento para se criar uma Framework própria.
Eu mesmo desenvolvi uma Framework de banco de dados própria onde através da criação das tabelas todo o código java para criação de Daos, Beans e Visões são gerados a partir das classes, mas claro que nem tudo será feito automaticamente, existem particularidades, cada caso é um caso.
O importante é o resultado final, onde uma aplicação é gerada, ficando a cargo do desenvolvedor(No caso eu) ajustar alguns pontos.