JDBC VS Hibernate
Nous utilisons JDBC depuis très longtemps dans nos applications Web. La principale raison pour laquelle nous l'avons utilisé est que nous contrôlons à 100% le code, SQL et que nous réglons les problèmes entre nos mains. En dehors de cela, nous avons utilisé des déclencheurs dans la base de données, laquelle est développée séparément par des experts de la base de données.
Cependant, beaucoup recommandent maintenant d'utiliser Hibernate et nous avons donc pensé à l'utiliser. Mais, nous avons trouvé les problèmes ci-dessous.
Hibernate ne peut pas se connecter avec une base de données "existante". Il essaie toujours de créer l'un des siens.
Notre base de données peut accéder par la même application qui se trouve sur différentes plates-formes (cloud, serveur, VPS, ordinateur personnel). Hibernate peut poser des problèmes en raison de sa mise en cache dans cette situation.
Nous n'aimons jamais donner le "travail de création de table" au code Java. Nous créons des tables manuellement, toujours.
Nous pourrions être amenés à utiliser des instructions SQL très longues et complexes. La dernière fois, nous avons utilisé une instruction comportant plus de 150 lignes et joignant plus de 20 tables. Nous doutons que nous ayons à faire face à des problèmes en ce qui concerne Hibernate.
Notre code SQL est gentil et standard. Le code généré par Hibernate semble être un peu sale pour nous.
Nous utilisons toujours MySQL. Ne jamais utiliser une autre base de données.
Les applications que nous créons nécessitent une sécurité maximale, liée au médical. Si au moins un enregistrement de données est divulgué, nous avons terminé.
Il y a beaucoup de
foreign keys,Primary Keys,Composite Keys,Unique Keysetc etc. dans la base de données. Dans les forums, certains se sont plaints qu'Hibernate ait gâché ceux-ci.Nous avons décidé d'essayer d'hiberner parce que certaines personnes affirment: «Êtes-vous des ingénieurs en logiciel? Vous utilisez déjà la version morte
JDBC!!.».
Compte tenu de ces éléments, merci de me faire savoir si les points ci-dessus sont réellement vrais (comme je l'ai dit, je les ai connus via Google, discussion, etc.) ou non. Et quels sont les avantages et les inconvénients d'Hibernate VS Java JDBC?
Répondre aux problèmes énumérés ci-dessus:
1. Hibernate ne peut pas se connecter à une base de données "existante". Il essaie toujours de créer sa propre base de données.
C'est faux. Hibernate can se connecte à une base de données existante et ne tente pas toujours de la recréer. Vous devriez juste activer un paramètre comme hbm2ddl. auto.
2. Notre base de données peut accéder par la même application située sur différentes plates-formes (cloud, serveur, VPS, ordinateur personnel). Hibernate peut créer des problèmes en raison de sa mise en cache, dans cette situation.
Hibernate a un cache ajustable, donc ce n’est pas un problème.
3. Nous n'aimons jamais donner du "travail de création de table" au code Java. Nous créons des tables manuellement, toujours.
Aucun problème. Voir p.1 ci-dessus. De plus, il existe plusieurs bibliothèques pratiques pour la création et la mise à jour indirectes de tables (par exemple, liquibase ), qui peuvent être utilisées parfaitement en mode veille prolongée.
4. Il se peut que nous devions utiliser des instructions SQL très longues et complexes. La dernière fois, nous utilisions une instruction de plus de 150 lignes, joignant plus de 20 tables. Nous doutons que nous aurons des problèmes en ce qui concerne Hibernate.
Vous pouvez toujours utiliser des appels JDBC directs et invoquer des requêtes SQL natives via hibernate, le cas échéant.
5. Notre code SQL est gentil et standard. Le code généré par Hibernate semble être un peu sale pour nous.}
Encore une fois, si vous devez invoquer du code SQL compliqué et logique au lieu d’hibernate généré automatiquement, vous pouvez le faire.
6. Nous utilisons toujours MySQL. N'utilisez jamais d'autre base de données.
Pas un problème du tout. Hibernate prend en charge le dialecte MySQL: org.hibernate.dialect.MySQLDialect.
7. L'application que nous créons nécessite une sécurité maximale, liée aux soins médicaux. Si au moins un enregistrement de données présente une fuite, nous avons terminé.
Les problèmes de sécurité ne sont pas liés aux techniques ORM. Hibernate est juste une couche logique et pratique orientée objet entre des appels JDBC de base de données pure et des outils de programmation. Cela n'a aucune influence sur la sécurité commune du réseau.
Hibernate est un excellent outil et vous y trouverez une foule de documentations , livres et articles de blog à ce sujet.
Je vais répondre à toutes vos préoccupations:
Hibernate ne peut pas se connecter avec une base de données "existante". Il essaie toujours de créer l'un des siens.
Hibernate devrait utiliser une procédure de gestion de schéma de base de données distinct même pour les tests d'intégration . Vous devez utiliser un outil de gestion de version incrémentielle tel que FlywayDB pour gérer vos modifications de schéma.
Notre base de données peut accéder par la même application qui se trouve sur différentes plates-formes (cloud, serveur, VPS, ordinateur personnel). Hibernate peut poser des problèmes en raison de sa mise en cache dans cette situation.
Vous n'êtes pas obligé d'utiliser le cache de second niveau, qui utilise des implémentations de mise en cache tierces. Toutes les solutions de mise en cache risquent de casser la cohérence transactionnelle . Le cache de premier niveau garantit reproductible au niveau de la session reads et avec le verrouillage optimiste en place, vous pouvez empêcher les mises à jour perdues .
Nous n'aimons jamais donner le "travail de création de table" au code Java. Nous créons des tables manuellement, toujours.
La gestion de la base de données doit être séparée de votre outil ORM. C'est une bonne pratique quand même.
Nous pourrions être amenés à utiliser des instructions SQL très longues et complexes. La dernière fois, nous avons utilisé une instruction comportant plus de 150 lignes et joignant plus de 20 tables. Nous doutons que nous ayons à faire face à des problèmes en ce qui concerne Hibernate.
Hibernate est idéal pour les opérations d'écriture et pour le contrôle de la simultanéité. Vous devez toujours utiliser le SQL natif pour les requêtes avancées (fonctions de fenêtre, CTE). Mais Hibernate vous permet d’exécuter des requêtes natives.
Notre code SQL est gentil et standard. Le code généré par Hibernate semble être un peu sale pour nous.
De toute façon, vous n’avez pas besoin et vous ne devriez probablement pas utiliser l’utilitaire hbmdll.
Nous utilisons toujours MySQL. Ne jamais utiliser une autre base de données.
C'est même mieux. Vous pouvez donc utiliser des requêtes natives avancées sans vous soucier des problèmes de portabilité de la base de données.
Les applications que nous créons nécessitent une sécurité maximale, liée au médical. Si au moins un enregistrement de données est divulgué, nous avons terminé.
Hibernate ne vous empêche pas de sécuriser votre base de données ou le code d'accès aux données. Vous pouvez toujours utiliser les mesures de sécurité de la base de données avec Hibernate. Vous pouvez même utiliser Jasypt pour activer toutes sortes de fonctionnalités liées à la sécurité:
- hachage de mot de passe avancé
- cryptage bidirectionnel
Il y a beaucoup de clés étrangères, clés primaires, clés composites, clés uniques, etc. dans la base de données. Dans les forums, certains se sont plaints qu'Hibernate ait gâché ceux-ci.
Tout cela est supporté par Hibernate. Outre les conventions JPA, Hibernate propose également une cartographie particulière / pour toute cartographie exotique.
Nous avons décidé d'essayer d'hiberner parce que certaines personnes affirment: «Êtes-vous des ingénieurs en logiciel? Vous utilisez déjà JDBC mort!!».
Ce n'est pas le bon argument pour passer d'une bibliothèque que vous maîtrisez déjà. Si vous pensez que vous pouvez tirer parti d’Hibernate, c’est la seule raison impérieuse de passer de JDBC.
L'utilisation de JDBC pur et simple ne signifie pas que vous faites défaut dans l'industrie informatique, mais Hibernate utilise également JDBC dans la couche sous-jacente.
Quels avantages cela nous donne ce que nous devrions rechercher.
1.) Cache Mécanisme.
2.) Gérer sessions, transactions etc.
3.) Réduisez les efforts d'écriture de requêtes, plus d'utilitaires d'hibernation comme Query API, Criteria API, HQL
Les questions que vous avez soulevées sont plus ou moins couvertes dans Documents d'Hibernate .
Ehcache, infinispan, dépend du serveur que nous déployons, JBOSS, Weblogic, Tomcat, etc. ++ environnement comme le cloud, le cache distribué, etc.
Hibernate vous offre toujours la possibilité de désactiver automatiquement la création de schéma et de pointer vers celui que vous avez créé.
Voici les réponses rapides que je connais
1) Vous pouvez vous connecter à une base de données existante. Mais oui comme indiqué ici
Si vous n'avez pas de modèle objet solide, je dirais qu'Hibernate est un choix terrible.
2) L’accès à votre base de données à partir de différentes applications vous permet de conserver des verrous. D'autre part, vous pouvez trun-off mettre en cache comme fait ici .
3) Vous pouvez créer des tables manuellement et le connecter à l’aide du fichier .hbm.xml.
4) Vous pouvez utiliser n’importe quel type de requête en veille prolongée comme des critères de requête SQL simples.
5) Vous pouvez utiliser directement le code SQL dans Hibernate, si vous le souhaitez. Une autre option consiste à utiliser des critères.
6) Hibernate n'est PAS spécifique à la base de données. Vous pouvez choisir n'importe quelle base de données et la connecter avec hibernate.
7) En utilisant des verrous et en donnant des droits dans la base de données, vous pouvez maintenir la sécurité.
8) Convenu que les clés étrangères sont en désordre dans Hibernate Si vous ne le manipulez pas bien. Alors utilisez l’approche OO et maintenez bien les cascades, alors Hibernate sera un bon choix.