Java - Alternatives JDBC
ce n'est qu'une question théorique.
J'utilise JDBC avec mes Java pour utiliser la base de données (sélectionner, insérer, mettre à jour, supprimer ou autre). Je fais "manuellement" Java classes qui contiendront les données des tables DB (attribut = colonne db). Ensuite, je fais des requêtes (ResultSet) et remplis ces classes avec des données. Je ne suis pas sûr, si c'est la bonne façon.
Mais j'ai lu beaucoup de choses sur JDO et d'autres solutions de persistance.
Quelqu'un peut-il recommander les meilleures alternatives JDBC utilisées, en fonction de son expérience?
J'aimerais également connaître les avantages de JDO par rapport à JDBC (en termes simples).
J'ai pu google beaucoup de ce genre de choses, mais les opinions de première main sont toujours les meilleures.
Merci
L'histoire de la persistance de la base de données dans Java est déjà longue et pleine de rebondissements:
JDBC est l'API de bas niveau qui tout le monde utilise à la fin pour parler à une base de données. Mais sans utiliser une API de niveau supérieur, vous devez faire tout le travail de grognement vous-même (écrire des requêtes SQL, mapper les résultats aux objets, etc.).
EJB 1.0 CMP Entity Beans était un premier essai pour une API de niveau supérieur et a été adopté avec succès par les grands fournisseurs Java EE (BEA, IBM) mais pas par les utilisateurs) Les Entity Beans étaient trop complexes et avaient trop de surcharge (comprenez, mauvaise performance). FAIL!
EJB 2.0 CMP a essayé de réduire une partie de la complexité des Entity Beans avec l'introduction d'interfaces locales, mais la majorité de la complexité est restée. EJB 2.0 manquait également de portabilité (car le mappage relationnel-objet ne faisait pas partie de la spécification et le descripteur de déploiement était donc propriétaire). ÉCHEC!
Puis vint JDO qui est un standard agnostique de banque de données pour la persistance des objets (peut être utilisé avec RDBMS, OODBMS, XML, Excel, LDAP). Mais, bien qu'il existe plusieurs implémentations open source et que JDO ait été adopté par de petits fournisseurs indépendants (principalement des fournisseurs OODBMS espérant que les utilisateurs JDO passeront plus tard de leur banque de données RDBMS à un OODBMS - mais cela n'a évidemment jamais eu lieu), il n'a pas réussi à être adopté par les grands Java EE (à cause du tissage qui était pénible au moment du développement et d'effrayer certains clients, d'une API de requête étrange, d'être en fait trop abstrait). la norme elle-même n'est pas morte, je la considère comme un échec. FAIL!
Et en effet, malgré l'existence de deux normes, les API propriétaires comme Toplink, un ancien joueur, ou Hibernate ont été préférées par les utilisateurs à EJB CMP et JDO pour l'objet à la base de données relationnelle la persistance (la concurrence entre les normes, le positionnement peu clair de JDO, l'échec antérieur du CMP et le mauvais marketing ont une part de responsabilité à cet égard, je crois) et Hibernate est en fait devenu la norme de facto dans ce domaine (c'est un excellent cadre open source). SUCCÈS!
Ensuite, Sun a réalisé qu'ils devaient simplifier les choses (et plus généralement l'ensemble Java EE) et ils l'ont fait en 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 de la base de données objet à relationnelle. JPA unifie le CMP EJB 2 , JDO, Hibernate et TopLink API/produits et semble réussir là où EJB CMP et JDO ont échoué (facilité d'utilisation et adoption). SUCCÈS!
Pour résumer, la norme Java pour persistance de la base de données est JPA et devrait être préférée aux autres API propriétaires (utiliser l'implémentation Hibernate de JPA est très bien mais utilisez l'API JPA) à moins qu'un ORM ne soit pas ce dont vous avez besoin. Il fournit une API de niveau supérieur à JDBC et est destiné à vous faire économiser beaucoup de travail manuel (c'est simplifié mais c'est l'idée).
Si vous voulez écrire du SQL vous-même et ne voulez pas d'ORM, vous pouvez toujours bénéficier de certains frameworks qui masquent toute la gestion fastidieuse des connexions (try-catch-finally). Finalement, vous oublierez de fermer une connexion ...
Un tel framework qui est assez facile à utiliser est Spring JdbcTemplate .
Je peux recommander Hibernate . Il est largement utilisé (et pour de bonnes raisons), et le fait que la spécification Java Persistence API était dirigée par le concepteur principal d'Hibernate garantit qu'elle sera présente dans un avenir prévisible :-) Si la portabilité et la neutralité du fournisseur est importante pour vous, vous pouvez l'utiliser via JPA, donc à l'avenir vous pourrez facilement passer à une autre implémentation JPA.
Faute d'expérience personnelle avec JDO, je ne peux pas vraiment comparer les deux. Cependant, les avantages d'Hibernate (ou ORM en général) à première vue semblent être à peu près les mêmes que ceux répertoriés sur la page JDO . Pour moi, les points les plus importants sont:
- Neutralité des bases de données: Hibernate prend en charge plusieurs dialectes SQL en arrière-plan, la commutation entre les bases de données est aussi simple que de changer une seule ligne dans votre configuration
- performances: récupération paresseuse par défaut, et beaucoup plus d'optimisations en cours sous le capot, que vous auriez besoin de gérer manuellement avec JDBC
- vous pouvez vous concentrer sur votre modèle de domaine et OO concevoir au lieu de problèmes de base de données de niveau inférieur (mais vous pouvez bien sûr affiner DML et DDL si vous le souhaitez)
Un inconvénient potentiel (des outils ORM en général) est qu'il n'est pas adapté au traitement par lots. Si vous devez mettre à jour 1 million de lignes dans votre table, ORM par défaut ne fonctionnera jamais aussi bien qu'une mise à jour par lots JDBC ou une procédure stockée. Hibernate peut cependant incorporer 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 si c'est à la tâche à cet égard par rapport à JDBC - mais à en juger par ce que je savoir jusqu'à présent, probablement oui). Donc, si votre application nécessite un traitement par lots mais traite principalement d'entités individuelles, Hibernate peut toujours fonctionner. S'il s'agit principalement d'un traitement par lots, JDBC est peut-être un meilleur choix.
Hibernate nécessite que vous disposiez d'un modèle d'objet auquel mapper votre schéma. Si vous ne pensez toujours qu'en termes de schémas relationnels et SQL, Hibernate n'est peut-être pas pour vous.
Vous devez être prêt à accepter le SQL qu'Hibernate va générer pour vous. Si vous pensez que vous pouvez faire mieux avec SQL codé à la main, Hibernate n'est peut-être pas pour vous.
Une autre alternative est iBatis. Si JDBC est du SQL brut et Hibernate est de l'ORM, iBatis peut être considéré comme quelque chose entre les deux. Il vous donne plus de contrôle sur le SQL exécuté.
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é aux bases de données.
Cela signifie que JDBC vous donnera un meilleur contrôle, mais il 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 JDO efficacement, ou Hibernate, ou tout autre outil d'abstraction supérieur. Sinon, vous pouvez rencontrer un scénario où les outils ORM présentent un comportement que vous ne comprenez pas.
Sun Java sur leur site Web fournit un matériel d'introduction décent qui vous guide à travers JDBC. http://Java.Sun.com/docs/books/tutorial/jdbc/ =.
Jetez un œil à MyBatis. Souvent ignoré, mais idéal pour les requêtes complexes en lecture seule utilisant les fonctionnalités propriétaires de votre SGBD.
JPA/Hibernate est un choix populaire pour ORM. Il peut vous fournir à peu près toutes les fonctionnalités ORM dont vous avez besoin. La courbe d'apprentissage peut être abrupte pour ceux qui ont des besoins de base en ORM.
Il existe de nombreuses alternatives à JPA qui fournissent ORM avec moins de complexité pour les développeurs ayant des exigences ORM de base. Interrogez sourceforge par exemple: http://sourceforge.net/directory/language:Java/?q=ORM
Je suis partisan de ma solution, Sormula: sourceforge ou bitbucket . Sormula a été conçu pour minimiser la complexité tout en fournissant un ORM de base.
Voici comment cela se passe avec Java persistence. Vous venez d'apprendre Java, maintenant vous voulez conserver certains enregistrements, vous apprenez JDBC. Vous êtes heureux de pouvoir maintenant enregistrer vos données dans un Ensuite, vous décidez d'écrire une application un peu plus grande. Vous vous rendez compte qu'il est devenu fastidieux d'essayer, d'attraper, d'ouvrir une connexion, de fermer la connexion, de transférer des données de l'ensemble de résultats vers votre bean .... Donc, vous pensez qu'il doit y avoir un moyen plus simple . En Java il y a toujours une alternative. Donc vous faites quelques recherches sur Google et en peu de temps vous découvrez ORM, et très probablement, hibernez. Vous êtes tellement excité que vous n'avez plus à penser à connexions. Vos tables sont créées automatiquement. Vous pouvez vous déplacer très rapidement. Ensuite, vous décidez d'entreprendre un très gros projet, d'abord vous vous déplacez très rapidement et vous avez toutes les opérations crud en place. Les exigences continuent à venir, puis un jour vous êtes coincé. Vous essayez d'enregistrer mais ce n'est pas en cascade aux objets enfants. dans les livres que vous avez lus. Vous ne savez pas quoi faire car vous n'avez pas écrit les bibliothèques d'hibernation. Vous souhaitez avoir écrit le SQL vous-même. Il est maintenant temps de repenser à nouveau ... À mesure que vous mûrissez, vous réalisez que la meilleure façon d'interagir avec la base de données est via SQL. Vous réalisez également que certains outils vous permettent de démarrer très rapidement, mais ils ne peuvent pas vous permettre de continuer longtemps. C'est mon histoire. Je suis maintenant un ibatis/utilisateur très heureux.
Il y a aussi le couple ( http://db.Apache.org/torque/ ) que je préfère personnellement parce que c'est plus simple et fait exactement ce dont j'ai besoin.
Avec le couple, je peux définir une base de données avec mysql (Eh bien, j'utilise Postgresql, mais Mysql est également pris en charge) et Torque peut alors interroger la base de données puis générer Java classes pour chaque table de la base de données. Avec Couple, vous pouvez ensuite interroger la base de données et récupérer Java objets du type correct.
Il prend en charge les clauses where (avec un objet Criteria ou vous pouvez écrire le sql vous-même) et les jointures.
Il prend également en charge les clés étrangères, donc si vous avez une table User et une table House, où un utilisateur peut posséder 0 maison ou plus, il y aura une méthode getHouses () sur l'objet utilisateur qui vous donnera la liste des objets House que propre à l'utilisateur.
Pour avoir un premier aperçu du type de code que vous pouvez écrire, consultez http://db.Apache.org/torque/releases/torque-3.3/tutorial/step5.html qui contient des exemples qui montrent comment charger/enregistrer/interroger des données avec un couple. (Toutes les classes utilisées dans cet exemple sont générées automatiquement en fonction de la définition de la base de données).
Ebean ORM est une autre alternative http://ebean-orm.github.io/
Ebean utilise les annotations JPA pour le mappage, mais il est conçu pour être sans session. Cela signifie que vous n'avez pas les concepts attachés/détachés et que vous ne persistez/fusionnez/purgez - vous enregistrez simplement () vos beans.
- Je m'attendrais à ce qu'Ebean soit beaucoup plus simple à utiliser que Hibernate, JPA ou JDO
Donc, si vous recherchez une approche alternative puissante à JDO ou JPA, vous pouvez jeter un œil à Ebean.
Hibernate, sûrement. C'est populaire, il existe même une version .NET.
De plus, hibernate peut être facilement intégré au framework Spring.
Et, il s'adaptera principalement aux besoins des développeurs.
Une alternative nouvelle et passionnante est GORM , qui est l'implémentation ORM de Grails. Peut désormais être utilisé seul. Sous le capot, il utilise Hibernate, mais vous offre une belle couche sur le dessus avec des trouveurs dynamiques sympas, etc.
Toutes ces différentes couches d'abstraction utilisent finalement JDBC. L'idée est d'automatiser une partie du travail fastidieux et sujet aux erreurs de la même manière que les compilateurs automatisent une grande partie du travail fastidieux lors de l'écriture de programmes (redimensionnement d'une structure de données - pas de problème, juste recompiler).
Notez cependant que pour que cela fonctionne, il y a des hypothèses auxquelles vous devrez adhérer. Ceux-ci sont généralement raisonnables et assez faciles à utiliser, surtout si vous commencez avec le côté Java par opposition à devoir travailler avec des tables de base de données existantes.
JDO est la convergence des différents projets en un seul standard Sun et celui que je vous suggère d'apprendre. Pour l'implémentation, choisissez celui que votre IDE suggère dans ses différents assistants).
Je recommande d'utiliser Hibernate, sa façon vraiment fantastique de se connecter à la base de données, auparavant, il y avait peu de problèmes, mais plus tard, il est plus stable. Il utilise le mappage basé sur ORM, il réduit votre temps sur l'écriture des requêtes dans une certaine mesure et il permet de changer les bases de données à un minimum d'effort. Si vous avez besoin de didacticiels basés sur la vidéo, faites-le moi savoir que je peux installer mon serveur et vous envoyer le lien.
Voici comment cela se passe avec Java persistence. Vous venez d'apprendre Java, maintenant vous voulez conserver certains enregistrements, vous apprenez JDBC. Vous êtes heureux de pouvoir maintenant enregistrer vos données dans un Ensuite, vous décidez d'écrire une application un peu plus grande. Vous vous rendez compte qu'il est devenu fastidieux d'essayer, d'attraper, d'ouvrir une connexion, de fermer la connexion, de transférer des données de l'ensemble de résultats vers votre bean .... Donc, vous pensez qu'il doit y avoir un moyen plus simple . En Java il y a toujours une alternative. Donc, vous faites quelques recherches sur Google et en peu de temps vous découvrez ORM, et très probablement, hibernez. Vous êtes tellement excité que vous n'avez plus à penser à connexions. Vos tables sont créées automatiquement. Vous pouvez vous déplacer très rapidement. Ensuite, vous décidez d'entreprendre un très gros projet, au départ, vous vous déplacez très rapidement et vous avez toutes les opérations crud en place.