web-dev-qa-db-fra.com

Quel Java ORM préférez-vous et pourquoi?

C'est une question assez ouverte. Je vais commencer un nouveau projet et je cherche différents ORM à intégrer à l'accès à la base de données.

Avez-vous des favoris? Y a-t-il des personnes que vous conseilleriez d'éviter?

javaorm
249
Mike

J'ai cessé d'utiliser les ORM.

La raison n'est pas un gros défaut dans le concept. Hibernate fonctionne bien. Au lieu de cela, j'ai constaté que les requêtes nécessitaient peu de temps système, que je pouvais intégrer beaucoup de logique complexe à de grandes requêtes SQL et transférer une grande partie de mon traitement dans la base de données.

Pensez donc simplement à utiliser le package JDBC.

229
David Crawshaw

Aucun, car avoir un ORM enlève trop de contrôle avec de petits avantages. Les gains de temps que vous gagnez sont facilement supprimés lorsque vous devez corriger des anomalies résultant de l'utilisation de l'ORM. De plus, les ORM découragent les développeurs d'apprendre le langage SQL, le fonctionnement des bases de données relationnelles et de l'utiliser à leur avantage.

95
simon

Beaucoup d'ORM sont géniaux, vous devez savoir pourquoi vous voulez ajouter de l'abstraction à JDBC. Je peux vous recommander http://www.jooq.org (avertissement: je suis le créateur de jOOQ, cette réponse est donc biaisée). jOOQ adopte le paradigme suivant:

  • SQL est une bonne chose. Beaucoup de choses peuvent être très bien exprimées en SQL. Il n'est pas nécessaire d'avoir une abstraction complète de SQL.
  • Le modèle de données relationnel est une bonne chose. Il s’est avéré le meilleur modèle de données pour les 40 dernières années. Les bases de données XML et les modèles de données véritablement orientés objet ne sont pas nécessaires. Au lieu de cela, votre entreprise exécute plusieurs instances d'Oracle, MySQL, MSSQL, DB2 ou de tout autre SGBDR.
  • SQL a une structure et une syntaxe. Elle ne doit pas être exprimée à l'aide d'une concaténation de chaînes "de bas niveau" dans JDBC - ou d'une concaténation de chaînes "de haut niveau" dans HQL - les deux étant susceptibles de contenir des erreurs de syntaxe.
  • La liaison variable a tendance à être très complexe lorsqu'il s'agit de requêtes majeures. C’est quelque chose qui devrait être résumé.
  • Les POJO sont excellents pour écrire Java code manipulant des données de base de données.
  • Les POJO sont difficiles à écrire et à maintenir manuellement. La génération de code est la voie à suivre. Vous aurez des requêtes sécurisées contre la compilation, y compris la sécurité du type de données.
  • La base de données vient en premier. Bien que l’application située au-dessus de votre base de données puisse changer au fil du temps, la base de données elle-même durera probablement plus longtemps.
  • Oui, vous avez des procédures stockées et des types définis par l'utilisateur (UDT) dans votre base de données existante. Votre outil de base de données devrait le supporter.

Il y a beaucoup d'autres bons ORM. Surtout Hibernate ou iBATIS ont une grande communauté. Mais si vous recherchez une solution intuitive et simple, je vous suggère d'essayer jOOQ. Tu l'adoreras! :-)

Découvrez cet exemple 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);

Et comment cela peut être exprimé en 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))))));
86
Lukas Eder

Hibernate, car c’est fondamentalement le standard de facto de Java et a été l’un des éléments moteurs de la création de JPA. Il dispose d’un excellent support au printemps, et presque tous les Java frameworks le prennent en charge. Enfin, GORM est un très bon emballage pour les recherches dynamiques, etc., à l’aide de Groovy.

Il a même été porté sur .NET (NHibernate) afin que vous puissiez l'utiliser là aussi.

57
Abdullah Jibaly

Hibernate, parce que ça:

  • est stable - étant autour pendant tant d'années, il ne manque aucun problème majeur
  • dicte les standards dans le domaine ORM
  • implémente la norme (JPA), en plus de la dicter.
  • a des tonnes d'informations à ce sujet sur Internet. Il existe de nombreux tutoriels, solutions aux problèmes courants, etc.
  • est puissant - vous pouvez traduire un modèle objet très complexe en un modèle relationnel.
  • il prend en charge tous les SGBDR majeurs et moyens
  • est facile à utiliser, ne fois que vous l’avez bien appris

Quelques points sur pourquoi (et quand) utiliser ORM:

  • vous travaillez avec des objets dans votre système (si votre système a été bien conçu). Même si vous utilisez JDBC, vous finirez par créer une couche de traduction afin de transférer vos données vers vos objets. Mais je parie que l'hibernation est meilleure pour la traduction que toute solution personnalisée.
  • cela ne vous prive pas de contrôle. Vous pouvez contrôler les choses dans de très petits détails, et si l'API n'a pas de fonctionnalité distante - exécutez une requête native et vous l'avez.
  • aucun système de taille moyenne ou plus grande ne peut se permettre d'avoir une tonne de requêtes (que ce soit au même endroit ou dispersées), si son objectif est de pouvoir être maintenues
  • si la performance n'est pas critique. Hibernate ajoute une surcharge de performances, qui dans certains cas ne peut être ignorée.
51
Bozho

Je recommanderais d'utiliser MyBatis . C'est une couche mince au-dessus de JDBC, il est très facile de mapper des objets sur des tables tout en utilisant du SQL pur, tout est sous votre contrôle.

25
adrian.tarau

J'ai eu une très bonne expérience avec Avaje Ebean lorsque j'écrivais une application JavaSE de taille moyenne.

Il utilise des annotations JPA standard pour définir des entités, mais expose une API beaucoup plus simple (pas de EntityManager ni aucune de ces entités liées/détachées). Il vous permet également d’utiliser facilement des requêtes SQL ou des appels JDBC simples en cas de besoin.

Il possède également une API très agréable, fluide et sécurisée pour les requêtes. Vous pouvez écrire des choses comme:

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

SimpleORM , parce que c'est simple et sans magie. Il définit toutes les structures de métadonnées dans le code Java et est très flexible.

SimpleORM fournit des fonctionnalités similaires à Hibernate en mappant les données d'une base de données relationnelle à Java objets en mémoire. Les requêtes peuvent être spécifiées en termes d'objets Java, l'identité de l'objet est alignée sur les clés de la base de données, les relations entre les objets sont conservées et les objets modifiés sont automatiquement vidés dans la base de données avec des verrous optimistes.

Mais contrairement à Hibernate, SimpleORM utilise une structure et une architecture d’objets très simples qui évitent le recours à des analyses complexes, au traitement de code octet, etc. SimpleORM est petit et transparent. Il est présenté dans deux pots de seulement 79 Ko et 52 Ko, dépendance (Slf4j). (Hibernate a une capacité de plus de 2 400 K + plus de 2 000 K de dépendants.) Cela simplifie la compréhension de SimpleORM et réduit donc considérablement les risques techniques.

11
David Schmitt

Eclipse Link , pour de nombreuses raisons, mais je pense notamment qu’elle a moins de problèmes que les autres solutions de flux principales (au moins moins de problèmes).

Oh et Eclipse Link a été choisi comme implémentation de référence pour JPA 2.0.

10
Tom Neyland

Bien que je partage les préoccupations concernant les remplacements Java des requêtes SQL de forme libre, je pense vraiment que les personnes critiquant ORM le font en raison d'une conception d'application généralement médiocre.

Le vrai OOD est déterminé par les classes et les relations, et ORM vous fournit un mappage cohérent de différents types et objets de relations. Si vous utilisez un outil ORM et finissez par coder des expressions de requête dans le langage de requête pris en charge par la structure ORM (y compris, sans toutefois s'y limiter, Java arbres d'expression, méthodes de requête, OQL, etc.), vous faites certainement quelque chose. faux, c’est-à-dire que votre modèle de classe ne répond probablement pas à vos besoins comme il se doit. Une conception d'application propre n'a pas vraiment besoin de requêtes au niveau de l'application. J'ai récemment restructuré de nombreux projets utilisant un framework ORM de la même manière qu'ils utilisaient pour incorporer des constantes de chaîne SQL dans leur code. Au final, tout le monde était surpris de la simplicité et de la maintenance de l'ensemble de l'application, une fois que vous correspondez. votre modèle de classe avec le modèle d'utilisation. Certes, vous avez besoin d'un langage d'interrogation pour des fonctionnalités telles que la recherche, etc. dans un langage de requête dans le code de votre application. L'approche VIEW exploite également les capacités de la base de données et, via la matérialisation, peut être beaucoup plus performante que n'importe quel code SQL écrit à la main dans votre source Java. Donc, je ne vois aucune raison pour qu'une application non-triviale NE PAS utiliser ORM.

4
Mirko Klemm