Spring Data JDBC/Spring Data JPA vs Hibernate
Quels sont les scénarios types de la vie réelle dans lesquels on choisirait Spring Data JDBC/Spring Data JPA vs Hibernate? J'aimerais comprendre les scénarios dans lesquels l'une ou l'autre de ces implémentations est la mieux adaptée.
Comme @Naros l'a dit, la question telle qu'elle se trouve actuellement dans le titre ne fonctionne pas vraiment. Il semble que nous devrions vraiment examiner 4 options et énumérer principalement les avantages de chaque approche. Les inconvénients sont l'absence des avantages de l'autre:
JDBC sans données de printemps
Vous obtenez un contrôle à 100% de ce qui se passe. Rien n'est généré ou injecté par un framework. Cela peut sembler un désastre, mais si vous avez essayé de modifier les mappages et les configurations pour obtenir une implémentation JPA capable de faire ce que vous pourriez écrire en toute simplicité en Java et en SQL, vous comprendrez que cela peut être un gros pro.
Vous n'êtes pas obligé d'apprendre JPA, ni Spring Data. Personnellement, je pense que Spring Data est facile, mais je suis partial (voir mon profil). Mais JPA est certainement un défi, une fois que vous quittez la zone des entités triviales et de la configuration.
- aucune exigence pour la modélisation de votre modèle de domaine (JPA nécessite des constructeurs par défaut, par exemple)
Vous voudrez probablement utiliser une bibliothèque pour réduire le code standard. Jeter un coup d'œil à:
JOOQ
MyBatis
Spring JdbcTemplate (utilisable sans le reste du printemps)
QueryDsl
JDBC avec Spring Data
Vous bénéficiez des avantages de Spring Data, combinés à ceux de JDBC (voir ci-dessus):
Référentiels avec des méthodes CRUD prêtes à l'emploi.
Intégration agréable dans l'infrastructure Spring, pour la gestion des transactions, l'injection de dépendance, la traduction d'erreur, la pagination ...
C'est encore un modèle de programmation très simple. Les instructions SQL se produisent exactement au moment où l'on s'attend à ce qu'elles se produisent et si vous le souhaitez, vous pouvez vous rabattre sur un simple JDBC avec ou sans la prise en charge d'autres frameworks, sans interrompre aucune abstraction.
Bien que non disponible pour le moment, vous aurez encore plus de bonus avec les futures mises à jour:
Méthodes simples et agréables pour étendre vos référentiels avec des méthodes de requête (vous définissez simplement votre interface avec une méthode
findByLastNameet Spring la génère pour vous à la volée) ou des annotations ou méthodes personnalisées@query.Prise en charge de la pagination
Hibernate (ou une autre implémentation de JPA) sans Spring Data
JPA fait beaucoup de choses sur JDBC
Mise en cache (1er, 2e niveau et cache de requêtes)
Création automatisée d'instances à partir de requêtes
Navigation entre entités
Chargement paresseux
Avec tout ce qui se passe, il peut être difficile de comprendre ce qui se passe et pourquoi. Bien sûr, _ si _ si vous structuriez correctement votre application, vous pouvez vous contenter de JDBC si JPA n'offre pas ce que vous voulez. Mais j’ai vu à maintes reprises que des personnes n’avaient pas réussi à maintenir la structure nécessaire pour que cela fonctionne. Évidemment, cela est particulièrement difficile si vous ne comprenez pas bien le fonctionnement de JPA.
Hibernate (ou une autre implémentation de JPA) avec Spring Data
J'ai énuméré les avantages de Spring Data ci-dessus, effectuez simplement un copier-coller mental.
Bien sûr, cela rend la pile complète encore plus complexe. Parmi les nombreuses questions balisées avec Spring-data AND hibernate, il semble que de nombreux développeurs ont du mal à identifier quel outil fait quoi. Cependant, en regardant ces questions, la plupart des problèmes décrits concernent Hibernate/JPA et non Spring Data.
Pour conclure:
Si vous voulez/avez besoin d’un contrôle précis, utilisez JDBC.
Si vous souhaitez utiliser JPA, assurez-vous de bien le comprendre dès le début.
Si pour la technologie de persistance que vous choisissez, Spring Data propose un module, je l’utiliserais. Cela facilitera la vie. Mais encore une fois je suis partial.
Un problème avec votre question est que vous semblez impliquer que Spring Data JPA est comme Hibernate et que ce n’est pas le cas. Spring Data JPA est simplement un wrapper centré sur le printemps offrant une sémantique souple et des fonctionnalités qui encapsulent un fournisseur JPA dont Hibernate est une implémentation.
Ainsi, vous ne pouvez pas utiliser Spring Data JPA sans inclure une implémentation de JPA telle que Hibernate.
La question de base que vous posez est de savoir pourquoi utiliser JDBC contre un ORM. Afin de comprendre que vous devriez prendre le temps de comprendre les avantages d'un ORM. Il existe de nombreux articles sur Internet qui peuvent vous donner cela.
Mais même dans une application pilotée par ORM, vous aurez parfois des cas où vous devrez contourner le framework ORM et utiliser du SQL natif, comme vous le feriez dans JDBC. Ces cas sont souvent rares, mais nécessaires lorsque vous souhaitez tirer parti d'une fonctionnalité de base de données non prise en charge ou lorsque vous souhaitez avoir le contrôle ultime de la manipulation des résultats, etc.
Le facteur décisif à utiliser dépend finalement des besoins de votre application. Mais le fait que vous choisissiez d'utiliser une structure ORM n'exclut pas mutuellement la possibilité d'exécuter des requêtes natives et des instructions SQL comme vous le feriez dans JDBC. Ces fonctionnalités sont toujours disponibles, vous les utilisez généralement dans de rares cas.
check out requery.io , requery fournit des performances et ORM.
consultez également spring-data-requery
Le problème, c’est Spring, les données pour jpa sont une abstraction sur jpa, qui est une abstraction sur JDBC. Si offre de jolies fonctionnalités, même si jpa est utilisable sans elle. Il devient vraiment puissant avec Spring Data Rest.
Mais plus un cadre vous convient, plus vous avez besoin de comprendre la technologie sous-jacente. C'est encore plus vrai si vous utilisez spring-data-rest. Le mieux est de commencer par comprendre SQL (conception et requêtes), puis jpa (chargement différé, états d'instance, entités, objets intégrables, caches, requêtes, synchronisation des transactions).
Ensuite, vous essayez Spring-data-jpa et décidez si cela apporte de la valeur à votre projet. Pour les opérations save, update, delete et find by id, il s’agit essentiellement d’un wrapper autour des méthodes persist, merge, remove et find de EntityManager. Le principal avantage de Spring Data JPA est la prise en charge de la requête, mais querydsl est également une option intéressante. Dans les deux cas, cela nécessite une compréhension claire du fonctionnement de l'APP. La première chose à faire est d'activer la journalisation SQL pour voir si, pour un accès à une base de données donné, votre implémentation jpa exécute des requêtes qu'un dba considérerait comme correctes. Par exemple, un chargement rapide sur une entité qui n'est pas dans le cache entraîne une sélection 1 + n, votre test unitaire réussira et les problèmes commenceront en production. spring-data-jpa ne résoudra pas le problème pour vous.
Il existe de nombreuses sources-données-printemps à côté de données-jpa, certaines offrent également des annotations de mappage (telles que sources-données), ce qui est utile lorsqu'il n'y a pas de mappage objet-base de données.