Java - alternatives JDBC

Question

Il s'agit simplement d'une question théorique.

J'utilise JDBC avec mes applications Java pour accéder à la base de données (sélection, insertion, mise à jour, suppression, ou autre). Je crée "manuellement" des classes Java qui contiendront les données des tables de la base de données (attribut = colonne de la base de données). Ensuite, je fais des requêtes (ResultSet) et je remplis ces classes avec les données. Je ne suis pas sûr que ce soit la bonne approche.

Mais j'ai lu beaucoup de choses sur JDO et d'autres solutions de persistance.

Est-ce que quelqu'un peut recommander les meilleures alternatives à JDBC en fonction de son expérience ?

J'aimerais aussi connaître les avantages de JDO par rapport à JDBC (en termes simples).

J'ai pu trouver beaucoup d'informations à ce sujet sur Google, mais les opinions de première main sont toujours les meilleures.

Merci

Answer 1

L'histoire de la persistance des bases de données en Java est déjà longue et pleine de rebondissements :

• JDBC est l'API de bas niveau que tout le monde utilise pour communiquer avec une base de données. Mais sans utiliser une API de niveau supérieur, vous devez faire tout le travail vous-même (écrire des requêtes SQL, mapper les résultats sur des objets, etc).

• Les beans d'entité EJB 1.0 CMP étaient une première tentative pour une API de niveau supérieur et ont été adoptés avec succès par les grands fournisseurs de Java EE (BEA, IBM) mais pas par les utilisateurs. Les beans d'entité étaient trop complexes et avaient trop de surcharge (comprendre, des performances médiocres). ÉCHEC !

• EJB 2.0 CMP a tenté de réduire une partie de la complexité des beans d'entité avec l'introduction d'interfaces locales, mais la majorité de la complexité est restée. EJB 2.0 manquait également de portabilité (car le mapping objet-relationnel ne faisait pas partie de la spécification et les descripteurs de déploiement étaient donc propriétaires). ÉCHEC !

• Puis est arrivé JDO qui est une norme agnostique par rapport au stockage pour la persistance objet (peut être utilisé avec RDBMS, OODBMS, XML, Excel, LDAP). Mais, même s'il y a plusieurs implémentations open-source et même si JDO a été adopté par de petits fournisseurs indépendants (principalement des fournisseurs d'OODBMS espérant que les utilisateurs de JDO passeraient plus tard de leur RDBMS à un OODBMS - mais cela ne s'est évidemment jamais produit), il n'a pas été adopté par les grands acteurs et utilisateurs de Java EE (en raison du tissage qui était un problème au moment du développement et effrayait certains clients, d'une API de requête étrange, d'un caractère en fait trop abstrait). Donc, même si la norme elle-même n'est pas morte, je la considère comme un échec. ÉCHEC !

• Et en effet, malgré l'existence de deux normes, des API propriétaires comme Toplink, un ancien acteur, ou Hibernate ont été préférées aux CMP EJB et JDO pour la persistance d'objet vers une base de données relationnelle (concurrence entre les normes, positionnement peu clair de JDO, échec antérieur des CMP et mauvais marketing ont une part de responsabilité à mon avis) et Hibernate est en fait devenu la norme de facto dans ce domaine (c'est un excellent framework open source). SUCCÈS !

• Ensuite, Sun a réalisé qu'ils devaient simplifier les choses (et plus généralement toute la Java EE) et ils l'ont fait avec Java EE 5 avec JPA, l'API de persistance Java, qui fait partie d'EJB 3.0 et est la nouvelle norme pour la persistance d'objet vers une base de données relationnelle. JPA unifie les APIs / produits EJB 2 CMP, JDO, Hibernate et TopLink et semble réussir là où les CMP EJB et JDO ont échoué (facilité d'utilisation et d'adoption). SUCCÈS !

Pour résumer, la norme de Java pour la persistance des bases de données est JPA et devrait être préférée aux autres APIs propriétaires (utiliser l'implémentation de JPA de Hibernate est bien mais utilisez l'API JPA) à moins qu'un ORM ne soit pas ce dont vous avez besoin. Elle fournit une API de niveau supérieur à JDBC et est censée vous faire gagner beaucoup de travail manuel (c'est simplifié mais c'est l'idée).

Answer 2

Si vous voulez écrire du SQL vous-même et ne voulez pas utiliser un ORM, vous pouvez toujours bénéficier de certains frameworks qui cachent toute la gestion fastidieuse de la connexion (try-catch-finally). Finalement, vous oublierez de fermer une connexion...

Un tel framework qui est assez facile à utiliser est Spring JdbcTemplate.

Answer 3

Je peux recommander Hibernate. Il est largement utilisé (et à juste titre), et le fait que la spécification de l'API de persistance Java a été dirigée par le principal concepteur de Hibernate garantit qu'il sera là pour un avenir prévisible :-) Si la portabilité et la neutralité vis-à-vis des fournisseurs sont importantes pour vous, vous pouvez l'utiliser via JPA, afin de pouvoir facilement passer à une autre implémentation JPA à l'avenir.

N'ayant pas d'expérience personnelle avec JDO, je ne peux pas vraiment les comparer. Cependant, les avantages de Hibernate (ou de l'ORM en général) semblent à première vue être sensiblement les mêmes que ceux répertoriés sur la page JDO. Pour moi, les points les plus importants sont :

• Neutralité à la base de données : Hibernate prend en charge plusieurs dialectes SQL en arrière-plan, passer d'une BD à l'autre est aussi simple que de changer une seule ligne dans votre configuration
• performances : chargement paresseux par défaut, et bien plus d'optimisations se produisent en arrière-plan, que vous devriez gérer manuellement avec JDBC
• vous pouvez vous concentrer sur votre modèle de domaine et la conception OO plutôt que sur les problèmes de base de données de bas niveau (mais vous pouvez bien sûr peaufiner DML et DDL si vous le souhaitez)

Un inconvénient potentiel (des outils ORM en général) est qu'ils ne sont pas très adaptés au traitement par lots. Si vous devez mettre à jour 1 million de lignes dans votre table, l'ORM ne fonctionnera jamais aussi bien qu'une mise à jour par lots JDBC ou une procédure stockée par défaut. Hibernate peut cependant intégrer des procédures stockées, et il prend en charge le traitement par lots dans une certaine mesure (je ne suis pas encore familier avec cela, donc je ne peux pas vraiment dire s'il est à la hauteur de la tâche à cet égard par rapport à JDBC - mais d'après ce que je sais jusqu'à présent, probablement oui). Ainsi, si votre application nécessite un certain traitement par lots mais traite principalement d'entités individuelles, Hibernate peut quand même fonctionner. Si elle effectue principalement un traitement par lots, peut-être JDBC est un meilleur choix.

Answer 4

Hibernate nécessite que vous ayez un modèle d'objet pour mapper votre schéma. Si vous pensez toujours uniquement en termes de schémas relationnels et de SQL, peut-être que Hibernate n'est pas fait pour vous.

Vous devez être prêt à accepter le SQL que Hibernate générera pour vous. Si vous pensez pouvoir faire mieux avec du SQL codé à la main, peut-être que Hibernate n'est pas fait pour vous.

Une autre alternative est iBatis. Si JDBC est du SQL brut, et Hibernate est un ORM, iBatis peut être considéré comme quelque chose entre les deux. Il vous donne plus de contrôle sur le SQL qui est exécuté.

Answer 5

JDO s'appuie sur la technologie JDBC. De même, Hibernate nécessite également JDBC. JDBC est la spécification fondamentale de Java sur la connectivité des bases de données.

Cela signifie que JDBC vous donnera un plus grand contrôle mais cela nécessite plus de code de plomberie.

JDO fournit des abstractions plus élevées et moins de code de plomberie, car une grande partie de la complexité est cachée.

Si vous posez cette question, je suppose que vous n'êtes pas familier avec JDBC. Je pense qu'une compréhension de base de JDBC est nécessaire pour utiliser efficacement JDO, Hibernate, ou tout autre outil d'abstraction supérieure. Sinon, vous pouvez rencontrer des scénarios où les outils ORM présentent un comportement que vous ne comprendrez peut-être pas.

Le tutoriel Java de Sun sur leur site Web fournit un matériel introductif décent qui vous guide à travers JDBC. http://java.sun.com/docs/books/tutorial/jdbc/.