Pourquoi utiliser JPA au lieu d’écrire directement une requête SQL sur un fichier Java (c'est-à-dire directement dans JDBC)?
J'ai lu sur plusieurs articles ce qu'est JPA (Java Persistent API) et quel fournisseur le supportant (DataNucleus, JBoss Hibernate, etc.)
Je n'ai pas d'expérience avec ORM (mapping relationnel d'objet).
Jusqu'à présent, ce que j'ai fait est d'écrire mes propres classes de base de données à l'aide de DTO et DAO. Jusqu'à présent, je suis heureux de ce que j'ai mais aimerais savoir pourquoi les gens utilisent JPA sur un fichier Java qui contient SQL .
Pour moi, j’ai l’impression que l’écriture de cours DAO serait acceptable, comme ci-dessous.
public class DAOUsers {
public void insertNewUser(DTO DtoUser) {
String query = "INSERT INTO users(username, address) " +
"VALUES(DtoUser.username , DtoUser.address)";
Executor.run(query);
}
}
J'ai appris que JPA utilise JPQL, le langage de requête persistant Java, qui opère sur l'entité object Plutôt que directement avec les tables de base de données.
Ma compréhension (corrigez-moi si je me trompe) est que cet objet entité est identique à mon objet DTO (un peu comme un haricot?)
Mais quoi qu’il en soit, quel avantage JPA donne-t-il réellement à l’écriture de code SQL pur dans mon fichier?.
s'il vous plaît laissez-moi savoir si vous avez besoin de plus d'éclaircissements, je suis nouveau sur ce sujet et aimerais avoir votre opinion.
Pourquoi utiliser JPA au lieu de directement écrire une requête SQL sur un fichier Java (c'est-à-dire .. directement à JDBC)?
Certains projets nécessitent que les ingénieurs se concentrent davantage sur le modèle d'objet que sur les requêtes SQL utilisées pour accéder aux magasins de données. La question peut en réalité être interprétée comme
Pourquoi utiliser un framework ORM?
qui peut avoir différentes réponses dans différents contextes.
La plupart des projets peuvent tirer parti d'un modèle de domaine, la persistance constituant une seconde préoccupation. Avec JPA (implémentations) ou la plupart des autres infrastructures ORM, il est possible d’avoir toutes les entités, c’est-à-dire des tables dans votre base de données, modélisées comme des classes en Java. De plus, il est également possible d'incorporer un comportement dans ces classes et d'obtenir ainsi un modèle de domaine riche en comportement. Les entités de ce modèle peuvent avoir plusieurs objectifs, notamment celui de remplacer des DTO pour le transport de données sur plusieurs niveaux.
Cela dit, il existe des endroits où les frameworks ORM peuvent ne pas être une solution directe au problème, en particulier lorsque le modèle de données est déjà établi ou lorsque vous travaillez avec des systèmes hérités où le mappage de tables de base de données avec des classes Java est un exercice non trivial. Et dans certains cas, si vous avez absolument besoin d’optimiser le code SQL généré par le framework ORM, les frameworks ORM conviennent généralement mal.
Questions connexes
Quels sont les avantages réels de JPA par rapport à l'écriture de code SQL pur dans mon fichier?
Voici quelques avantages:
JPA vous permet d'éviter d'écrire DDL dans un dialecte SQL spécifique à la base de données. Au lieu de cela, vous écrivez des "mappages" en XML ou en utilisant des annotations Java.
JPA vous permet d'éviter d'écrire DML dans le dialecte SQL spécifique à la base de données.
JPA vous permet de charger et de sauvegarder des objets et des graphiques Java sans aucun langage DML.
Lorsque vous do devez exécuter des requêtes, JPQL vous permet d'exprimer les requêtes en termes d'entités Java plutôt qu'en tables (et tables) SQL (natives).
En règle générale, JPA est plus simple, plus propre et moins gourmand en travail que les mappages manuscrits JDBC + SQL +. Plus votre modèle de données est compliqué, plus il est bénéfique.
Toutefois, si les performances sont une préoccupation overriding, JPA a tendance à gêner en ajoutant des couches entre votre application et la base de données. Si votre application nécessite une optimisation manuelle poussée des requêtes et des schémas de base de données natifs afin d'optimiser les performances, JPA ne convient probablement pas.
JPA n’est probablement pas non plus pour vous si vous êtes beaucoup plus à l'aise en jonglant Java, JDBC et SQL dans la même application, que de laisser l'ORM s'occuper des détails compliqués. (Mais si vous l'êtes, vous êtes probablement minoritaire ...)
Bien qu’il s’agisse d’une question ancienne, j’ai le sentiment qu’elle mérite une nouvelle réponse. J'adopte tardivement JPA, je l'utilise de manière intermittente depuis quelques années et, même si j'ai été impressionné par la simplicité de la mise en place d'une nouvelle application, je ne suis vraiment pas impressionné. avec la performance, la complexité et la courbe d’apprentissage nécessaires pour effectuer correctement un JPA. Les réponses dans ce fil renforcent réellement ma position.
Tout d'abord, @vineet suggère que "les entités peuvent avoir plusieurs objectifs" ... ce que j'ai vu en production et que je dirais est encouragé par ORM. Voilà pour la cohésion et le principe de responsabilité unique. D'après mon expérience, ajouter des comportements aux entités de base de données est source de problèmes. Je le sais parce que je l'ai fait et que j'ai vécu pour le regretter.
Deuxièmement, il existe des alternatives simples à la complexité de JPA qui permettent d'utiliser des classes avec un SGBDR sans tout le poids (et les problèmes de performance) causés par la non-concordance que ORM tente (sans succès) de résoudre. Nous utilisons des outils de mappage de classes relationnelles non-JPA depuis une décennie dans une application contenant plus de 1 000 tables et nous ne voyons tout simplement pas en quoi JPA représente une amélioration par rapport à un accès plus direct à la base de données. JPA masque la puissance de la base de données en ajoutant une surcharge (sous la forme d'annotations et de JQL) au modèle de classe ... ne devrait-il pas fonctionner dans l'autre sens?
@water suggère de nombreuses choses qui sont vraies en théorie mais non pratiques en réalité. Par exemple, après avoir changé trois fois de base de données dorsale, je peux assurer aux lecteurs qu’il n’existe pas quelques modifications de configuration et vous avez terminé. Je suggère que, si vous passez beaucoup de temps à maintenir votre couche de persistance, votre modèle de base de données évolue et que vous fassiez le même travail, voire davantage, dans JPA. En particulier lorsque des requêtes non triviales dans JPA nécessitent l'utilisation de JQL!
Presque tout le monde prétend que les développeurs JPA n'ont pas besoin de connaître SQL. Ce que j’ai vu dans la pratique, c’est que nous devons maintenant apprendre le langage SQL et JQL. Apparemment, nous n’avons pas besoin de DDL - mais dans toute application non triviale bien sûr vous devez connaître DDL. Hibernate ne recommande même pas d'utiliser la génération automatique de DDL. Apparemment, nous n'avons pas à utiliser le format DML, sauf lorsque nous appelons une requête native, qui n'est bien sûr pas portable, efface le cache et présente les mêmes problèmes que JDBC ...
En fin de compte, dans une application correctement structurée où le modèle de domaine est indépendant de la logique métier, JPA fournit peu de fonctionnalités pour ce que j'ai trouvé être une courbe d'apprentissage très élevée, car le modèle de domaine est en réalité très facile à créer. . Je n'utiliserais pas directement JDBC, mais Apache DBUtils fournit un simple calque au-dessus de JDBC qui mappe des lignes sur des objets. Avec un peu d'effort, il peut fournir la plupart des avantages de JPA sans dissimulation ni surcharge.
Je développe des applications de base de données Java depuis JDBC 1.0, en utilisant diverses bibliothèques (et iODBC et ESQL avant JDBC). Pour des raisons de performances uniquement, j'ai terminé avec JPA. Mais même si la performance était meilleure, la courbe d’apprentissage et les abstractions incomplètes me donnent une sérieuse pause. JPA est complexe et tente de masquer des détails qui, à mon avis, doivent réellement être pris en compte par les développeurs. À titre d’exemple, nous avons récemment vu des commandes de suppression du problème 250 d’Hibernate lorsqu’une seule suffirait. JPA, de par sa nature, facilite ce type d’erreur.
Je ne défends pas JDBC, je défends simplement contre JPA. Les développeurs qui ne travaillent pas ou ne peuvent pas travailler en SQL ne devraient probablement pas écrire d’applications relationnelles - pas plus que des développeurs comme moi, qui ne pouvaient pas utiliser la calcul formel pour me sauver la vie, devraient écrire des jeux en 3D. Les développeurs qui utilisent SQL pour gagner leur vie devraient être horrifiés par le SQL contorsionné qui hiberne, envoie l’un au serveur, afin d’éviter les allers-retours qui ne devraient pas être nécessaires au départ.
Si cela est fait correctement, vous pouvez mapper des requêtes SQL directement aux objets Java avec des implémentations JPA telles que hibernate. J'ai récemment réalisé un projet dans lequel j'avais un POJO, 3 ou 4 annotations et un peu de code d'installation pour prendre une procédure stockée et la mapper directement à une liste d'objets (du type classe POJO). Pour moi, cela fait partie du pouvoir de JPA.
Si vous l'utilisez comme si vous utilisiez directement SQL + JDBC, je ne connais aucun avantage.
Il existe un article décent ici sur les avantages de JPA.
J'espère que cela t'aides.
Comme nous savons tous que cet objet est l’une des choses les plus importantes de notre vie et qu’il est très simple de programmer un objet pour simplifier tout problème .... Et si un objet est disponible là-bas, alors pourquoi nous utilisons une chose entière à la place de ce petit une partie de cette chose signifie objet ...
- si vous codez à la main des instructions SQL dans votre application d'entreprise, vous consacrez une quantité importante de votre temps de développement à la mise à jour et à la maintenance de votre couche de persistance.
En persistance, ==> Plus besoin des API JDBC pour les ensembles de résultats ou la gestion des données . ==> Cela permet de réduire les lignes de code, &&&&&& ==> Cela éloigne notre application du base de données SQL sous-jacente et dialecte SQL. Le passage à une autre base de données SQL nécessite peu de modifications dans le fichier de configuration Hibernate (écriture unique/exécution instantanée).
En outre, comme vous le savez le slogan de Java: "Ecrivez une fois, courez partout"
Également avec JPQL, vous pouvez exécuter vos requêtes JPQL sur chaque base de données (DB2, Oracle, etc.)