Qual Java ORM você prefere e por quê? [fechadas]


262

É uma pergunta bastante aberta. Iniciarei um novo projeto e estou olhando para diferentes ORMs para integrar com o acesso ao banco de dados.

Você tem algum favorito? Você recomendaria ficar longe de alguém?



Veja micro-orms - invólucros finos da tecnologia de acesso ao banco de dados da plataforma - como sql2o para Java github.com/aaberg/sql2o ou ServiceStack.OrmLite para .NET github.com/ServiceStack/ServiceStack.OrmLite
tomaszkubacki em

3
Depois de usar o ORM por mais de 5 anos, minha escolha pessoal é o Spring JDBC sobre o ORM e o segundo melhor é o iBatis (MyBatis), não gosto de hibernar por causa da curva de aprendizado, menos problemas de controle e desempenho.

Aqui está (também fechada) a lista de wrappers jdbc leves que podem ser usados ​​como alternativa aos orms completos: stackoverflow.com/questions/7137929/…
Vadzim

Respostas:


237

Eu parei de usar ORMs.

O motivo não é uma grande falha no conceito. O Hibernate funciona bem. Em vez disso, descobri que as consultas têm uma sobrecarga baixa e posso encaixar muita lógica complexa em grandes consultas SQL e mudar muito do meu processamento para o banco de dados.

Portanto, considere apenas usar o pacote JDBC.


81
É a mesma história repetidas vezes com o ORM: bom desenvolvimento inicial rápido e uma grande drenagem de seus recursos mais adiante no projeto ao rastrear bugs e ineficiências relacionados ao ORM. Eu também odeio o fato de que parece dar aos desenvolvedores a idéia de que eles nunca precisam escrever consultas otimizadas específicas.
Eelco 29/05

7
Ei, isso é verdade para grandes projetos da vida real?
santiagobasulto

30
Concordo. Uso o ORM há mais de 3 anos e não sei dizer quanto tempo foi desperdiçado (ainda é) para resolver problemas relacionados à persistência. Não temos controle algum sobre o que está acontecendo "oculto", as configurações são demais para serem gerenciadas com eficiência e existem comportamentos que podem deixar alguém louco. Por outro lado, tenho suporte para grandes bancos de dados e nunca preciso me preocupar com suas diferenças.
marcolopes

58
por que não usar os dois, dependendo da complexidade da consulta / transação? não é que eles sejam mutuamente exclusivos.
amphibient

6
@WillSheppard sim Will. Eu uso o Django ORM bastante e funciona muito bem. Eu acho que a diferença pode estar na natureza dinâmica do python (e perl). Usar um ORM em Java é uma dor. Mas em linguagens dinâmicas, pode ser realmente expressivo. Existem alguns projetos excelentes para incorporar operações ORM como DSLs em Python e são ótimos.
31513 santiago_asulto

97

Nenhum, porque ter um ORM tira muito controle com pequenos benefícios. As economias de tempo obtidas são facilmente reduzidas quando você precisa depurar anormalidades resultantes do uso do ORM. Além disso, os ORMs desencorajam os desenvolvedores a aprender SQL e como os bancos de dados relacionais funcionam e a usá-los em seu benefício.


4
Eu concordo com essa afirmação. Quanto do tempo total de desenvolvimento será consumido escrevendo código de persistência? Eu acho que menos de 10-15%
adrian.tarau

16
Depende. Claro, se você estiver usando apenas um tipo específico de banco de dados, é fácil evitar o uso de um ORM. No entanto, quando você precisa oferecer suporte a outros tipos de bancos de dados, ele pode se tornar rapidamente menos gerenciável.
Jason Baker

3
"As economias de tempo obtidas são facilmente perdidas quando você precisa depurar anormalidades resultantes do uso do ORM" Isso não é verdade quando a curva de habilidades é um fator decente ao escolher as opções de tecnologia.
precisa saber é o seguinte

7
Seu argumento pode ser oferecido contra o uso de qualquer biblioteca. Os maiores ganhos dos ORMs são unidades de trabalho, mapeamento de objetos, rastreamento de alterações, carregamento lento, migrações e relacionamentos. É uma coisa maravilhosa poder escrever user.profile.givenName e não se importar com a estrutura usada para armazenar os dados.
1228 Alex

1
Pode ser usado em qualquer biblioteca, mas em graus variados. Geralmente sou um grande defensor do uso de bibliotecas - por que reinventar a roda? No entanto, neste caso, sinto que o Hibernate é para a maioria dos usos muito pesado e um ORM mais leve seria mais preferível. Minhas experiências baseiam-se em vários anos de experiência no desenvolvimento do Hibernate e no aprendizado completo dos detalhes.
21614 simon

92

Muitos ORMs são ótimos, você precisa saber por que deseja adicionar abstração no JDBC. Posso recomendar o http://www.jooq.org para você (aviso: sou o criador do jOOQ, portanto, esta resposta é tendenciosa). O jOOQ adota o seguinte paradigma:

  • SQL é uma coisa boa. Muitas coisas podem ser expressas muito bem no SQL. Não há necessidade de abstração completa do SQL.
  • O modelo de dados relacionais é uma coisa boa. Ele provou o melhor modelo de dados nos últimos 40 anos. Não há necessidade de bancos de dados XML ou modelos de dados verdadeiramente orientados a objetos. Em vez disso, sua empresa executa várias instâncias do Oracle, MySQL, MSSQL, DB2 ou qualquer outro RDBMS.
  • SQL tem uma estrutura e sintaxe. Ele não deve ser expresso usando a concatenação de seqüência de caracteres "de baixo nível" no JDBC - ou concatenação de seqüência de caracteres de "alto nível" no HQL - ambas propensas a conter erros de sintaxe.
  • A ligação variável tende a ser muito complexa ao lidar com as principais consultas. Isso é algo que deve ser abstraído.
  • Os POJO são ótimos ao escrever código Java manipulando dados do banco de dados.
  • POJO's são difíceis de escrever e manter manualmente. A geração de código é o caminho a percorrer. Você terá consultas de segurança de compilação, incluindo segurança de tipo de dados.
  • O banco de dados vem em primeiro lugar. Embora o aplicativo no topo do seu banco de dados possa mudar com o tempo, o próprio banco de dados provavelmente vai durar mais tempo.
  • Sim, você possui procedimentos armazenados e tipos definidos pelo usuário (UDT) em seu banco de dados herdado. Sua ferramenta de banco de dados deve suportar isso.

Existem muitos outros bons ORMs. Especialmente o Hibernate ou o iBATIS têm uma ótima comunidade. Mas se você estiver procurando por uma intuitiva e simples, direi que experimente o jOOQ. Você vai amar! :-)

Confira este exemplo SQL:

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

E como isso pode ser expresso no jOOQ:

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

1
As ferramentas ORM são tão boas quanto você consegue usá-las corretamente. Existem projetos em que as ferramentas ORM funcionam como um encanto, enquanto em outros, elas não se encaixam bem. No final, é responsabilidade da equipe de desenvolvimento escolher a ferramenta certa para os requisitos do projeto. As ferramentas ORM são complexas. Infelizmente, apenas uma parte de todos os desenvolvedores gastará tempo para entender como eles funcionam. O resto apenas culpará a ferramenta e dirá que é ruim. A pergunta é: a resposta mais votada oferece os melhores conselhos? > Portanto, considere apenas usar o pacote JDBC. Realmente queremos usar JDBC simples?
21716 Vlad Mihalcea

Tento não deixar "O banco de dados vem primeiro". Um aplicativo contém as regras de negócios para os recursos solicitados por um cliente e eles quase nunca solicitam a criação de um banco de dados. Esse é um detalhe técnico determinado durante a implementação.
Kwebble # 3/16

58

Hibernate, porque é basicamente o padrão defacto em Java e foi uma das forças motrizes na criação do JPA. Ele possui excelente suporte no Spring e quase todo framework Java o suporta. Por fim, o GORM é um invólucro muito bacana para fazer buscas dinâmicas e assim por diante usando o Groovy.

Foi até portado para o .NET (NHibernate), para que você possa usá-lo também.


4
Também voto no Hib, mas com uma adição importante: devemos usar a API JPA apenas se a implementação do JPA for de fato fornecida pelo Hib.
Vladimir Dyuzhev 17/01/09

52

Hibernate, porque:

  • é estável - estando presente por muitos anos, não possui grandes problemas
  • dita os padrões no campo ORM
  • implementa o padrão (JPA), além de ditá-lo.
  • tem toneladas de informações sobre isso na Internet. Existem muitos tutoriais, soluções de problemas comuns, etc.
  • é poderoso - você pode converter um modelo de objeto muito complexo em um modelo relacional.
  • suporta todos os principais e médios RDBMS
  • é fácil trabalhar, depois de aprender bem

Alguns pontos sobre por que (e quando) usar o ORM:

  • você trabalha com objetos no seu sistema (se o seu sistema foi bem projetado). Mesmo se você estiver usando o JDBC, você acabará criando uma camada de conversão para transferir seus dados para seus objetos. Mas minhas apostas são que o hibernar é melhor na tradução do que qualquer solução personalizada.
  • isso não o priva do controle. Você pode controlar as coisas com detalhes muito pequenos e, se a API não tiver algum recurso remoto - execute uma consulta nativa e você a possui.
  • qualquer sistema de tamanho médio ou maior não pode se dar ao luxo de ter uma tonelada de consultas (seja em um local ou espalhadas), se quiser manter a manutenção
  • se o desempenho não for crítico. O Hibernate adiciona sobrecarga de desempenho, que em alguns casos não pode ser ignorada.

Quando comparo o Hibernate e o JPA, vou para o Hibernate, e se comparar o JPA e o JDO, vou para o JDO! Eu gosto muito do JDO, mas adoro dois recursos do Hibernate (que não estão disponíveis no JDO), um é o @Filters e o outro é que você pode mapear os campos da versão (para bloqueio otimista) em campos normais, o que não é possível no JDO .
Amir Pashazadeh

27

Eu recomendaria usar MyBatis . É uma fina camada sobre o JDBC, é muito fácil mapear objetos para tabelas e ainda usar SQL simples, tudo está sob seu controle.


10
Ibatis para leituras complexas e hibernar para criar, atualizar exclusão e leituras simples é a escolha perfeita.
darpet

19

Eu tive uma experiência muito boa com o Avaje Ebean quando estava escrevendo um aplicativo JavaSE de tamanho médio.

Ele usa anotações JPA padrão para definir entidades, mas expõe uma API muito mais simples (Sem EntityManager ou qualquer uma dessas porcarias de entidades anexadas / desanexadas). Ele também permite usar facilmente consultas SQL ou chamadas JDBC sem eventos, quando necessário.

Ele também possui uma API fluida e de tipo seguro para consultas. Você pode escrever coisas como:

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

6
Eu devo ser um pouco esquisito ... selecione Pessoa onde sexo = 'M' e idade <18, ordenados por firstName, parecem muito melhores para mim :-)
Eelco

4
Esta é uma das melhores orms que eu já vi em java. Sua decisão de usar um singleton é refrescante e oferece uma enorme vantagem prática sobre os outros.
Opsb

Eu acho que você quer dizer fluente, não fluido.
Montdidier

@opsb Eu acho que tecnicamente é um monostate, não um singleton.
Montdidier

Como começar com o Avaje Ebean ORM? Algum vídeo Tutoriais ??
Avinash

11

SimpleORM , porque é simples e sem mágica. Ele define todas as estruturas de metadados no código Java e é muito flexível.

O SimpleORM fornece funcionalidade semelhante ao Hibernate, mapeando dados em um banco de dados relacional para objetos Java na memória. As consultas podem ser especificadas em termos de objetos Java, a identidade do objeto é alinhada com as chaves do banco de dados, os relacionamentos entre os objetos são mantidos e os objetos modificados são automaticamente liberados no banco de dados com bloqueios otimistas.

Mas, diferentemente do Hibernate, o SimpleORM usa uma estrutura e arquitetura de objetos muito simples que evita a necessidade de análise complexa, processamento de código de bytes, etc. O SimpleORM é pequeno e transparente, empacotado em dois frascos de apenas 79K e 52K de tamanho, com apenas um pequeno e opcional dependência (Slf4j). (O Hibernate tem mais de 2400K e mais de 2000K de frascos dependentes.) Isso torna o SimpleORM fácil de entender e reduz muito o risco técnico.


Ainda não o usei, mas o ActiveObjects se descreve como uma espécie de Hibernate-lite em seu site, então provavelmente há alguma semelhança.
Abdullah Jibaly

10

Eclipse Link , por muitas razões, mas principalmente sinto que ele tem menos inchaço do que outras soluções de fluxo principal (pelo menos menos inchaço na cara).

Oh e o Eclipse Link foi escolhido para ser a implementação de referência para o JPA 2.0


5

Embora eu compartilhe as preocupações com as substituições de Java para consultas SQL de forma livre, realmente acho que as pessoas que criticam o ORM estão fazendo isso por causa de um design de aplicativo geralmente ruim.

O OOD verdadeiro é orientado por classes e relacionamentos, e o ORM fornece mapeamento consistente de diferentes tipos e objetos de relacionamento. Se você usa uma ferramenta ORM e acaba codificando expressões de consulta em qualquer linguagem de consulta suportada pela estrutura ORM (incluindo, entre outras, árvores de expressão Java, métodos de consulta, OQL etc.), definitivamente está fazendo algo errado, ou seja, seu modelo de classe provavelmente não suporta seus requisitos da maneira que deveria. Um design de aplicativo limpo realmente não precisa de consultas no nível do aplicativo. Estive refatorando muitos projetos que as pessoas começaram usando uma estrutura ORM da mesma maneira que eram usadas para incorporar constantes de seqüência de caracteres SQL em seu código e, no final, todos ficaram surpresos com a simplicidade e a manutenção de todo o aplicativo depois de corresponder seu modelo de classe com o modelo de uso. É verdade que, para coisas como funcionalidade de pesquisa, etc., você precisa de uma linguagem de consulta, mas mesmo assim as consultas são tão restritas que criar uma VIEW e um mapeamento ainda mais complexos que para uma classe persistente somente leitura é muito melhor manter e olhar do que criar expressões em alguma linguagem de consulta no código do seu aplicativo. A abordagem VIEW também aproveita os recursos do banco de dados e, através da materialização, pode ser muito melhor em termos de desempenho do que qualquer SQL escrito à mão em sua fonte Java. Portanto, não vejo motivo para um aplicativo não trivial NÃO usar o ORM. mas, mesmo assim, as consultas são tão restritas que criar um VIEW e um mapeamento ainda mais complexos que é muito melhor manter e observar uma classe persistente somente leitura do que criar expressões em alguma linguagem de consulta no código do seu aplicativo. A abordagem VIEW também aproveita os recursos do banco de dados e, através da materialização, pode ser muito melhor em termos de desempenho do que qualquer SQL escrito à mão em sua fonte Java. Portanto, não vejo motivo para um aplicativo não trivial NÃO usar o ORM. mas, mesmo assim, as consultas são tão restritas que criar um VIEW e um mapeamento ainda mais complexos que é muito melhor manter e observar uma classe persistente somente leitura do que criar expressões em alguma linguagem de consulta no código do seu aplicativo. A abordagem VIEW também aproveita os recursos do banco de dados e, através da materialização, pode ser muito melhor em termos de desempenho do que qualquer SQL escrito à mão em sua fonte Java. Portanto, não vejo motivo para um aplicativo não trivial NÃO usar o ORM.


11
Se você está construindo aplicativos sobre uma loja persistente, como muitos de nós, seja um RDBMS ou algum tipo de NoSQL, essa loja terá sua própria maneira eficiente de acessá-lo. Tentar abstrair demais isso é apenas superengenharia. Ser excessivamente zeloso com o 'verdadeiro OOD' faz com que essas arquiteturas de astronautas sejam infames para Java.
Eelco
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.