Bonjour à tous, quelqu'un pourrait -il me donner quelques bonnes raisons pour utiliser hibernate, dans quels cas l'utiliser ou non ?
Merci d'avance pour vos réponses.
Version imprimable
Bonjour à tous, quelqu'un pourrait -il me donner quelques bonnes raisons pour utiliser hibernate, dans quels cas l'utiliser ou non ?
Merci d'avance pour vos réponses.
Cela reste personnel (et peu étoffé) mais:
Hibernate prmet de ne pas coder/gérer toute la partie JDBC/requête vers le base de données
Il y a plusieurs système de cache aux données
Un point où je ne l'utilise pas est lorsque la base est vraiment tordue(champs codés, champs ayant différents sens suivant d'autres champs)
Voila, je pense que nicgando a sommairement répondu à ta question. Au delà de la non gestion JDBC et requete (car, il est possible d'en faire tout de même), je parlerai vraiment de "boite à outils", mais aussi d'évolutivité, de maintenance, de portabilité, etc.
En effet, Hibernate est un framework de persistance. Il fournit donc tous les outils nécessaires à la gestion des données persistantes. On peut ainsi, par son intermédiaire, utiliser de nombreux autres outils liés à la persistance (cache, pool de connexion, transaction, etc.) sans pour autant veiller à leur "installation" au sein du projet. Seuls les paramétrages suffiront. En outre, en tant qu'API, il apporte de nombreuses classes et méthodes facilitant l'utilisation de langages indépendants de la BDD (Criteria, HQL, méthodes de Session) dans le but de communiquer avec la base de données et ainsi gérer la lecture et mise à jour de cette dernière sans passer par SQL et JDBC soi-même.
Cette indépendance justement est aussi la clé de sa portabilité, puisqu'elle lui permet de changer de base sans pour autant avoir à modifier le code applicatif. Une retouche aux fichiers de paramétrage sera suffisante. Toute évolution de la base ne nécessitera plus un parcours de toutes les classes avec modification des requêtes, mais uniquement une mise à jour du fichier de mapping, etc.
En résumé, cet outil (comme d'autres existant sur le marché également, JPOX en est un exemple) reste donc une aide précieuse dans la mise en place d'une nouvelle application nécessitant une communication avec base de données. Un bémol cependant, comme toute API, il possède ses limites et son intégration au sein de base peu normalisées peut poser des problèmes lors du mapping de la base avec modèle objet. Cependant, Hibernate laisse une certaine liberté au développeur (comparé aux autres outils existants en persistance de données) et lui permet ainsi trouver une parade à de nombreux problèmes.
Enfin, dernier point, tu trouveras pas mal de docs et une grosse communauté derrière pour t'aider, et cet avantage reste vraiment non négligeable :mrgreen:
Bonjour,
Je remonte ce sujet du fin fond du forum car c'est le seul que j'a trouvé à peu près en rapport avec la question que je me pose.
Je constate qu'Hibernate est un Framework très populaire ici est ailleurs. l n'y a qu'à voir le nombre de personnes qui disent l'utiliser pour s'en rendre compte. En ce qui me concerne, je n'avais jamais eu l'occasion de l'utiliser jusqu'à il y a quelque mois. Avant que je ne l'utilise je me demandais ce qu'un tel framework pouvait bien m'apporter. Le mapping relationnel/objet ne m'interressait à priori pas. J'étaits très content de JDBC et je n'avais pas l'envie d'aller voir ailleurs. Et puis il y a quelques mois j'ai eu l'occasion de l'utiliser sur un projet et je dois dire que les doutes que j'avais sur l'utilité de ce framework se sont confirmés. Après 4 mois d'utilisation du framework j'en suis venu à le detester cordialement.
En gros, ce que je reproche c'est :
- le mapping relationnel/objet : Certains ici semblent trouver cela très bien. Moi je n'aime pas du tout. Disons que sur le principe je trouve cela assez séduisant de manipuler des objets. Dans la pratique je trouve cela très fastideux tout simplement car le SGBDR n'étant lui pas objet cela m'oblige à une gymnastique désagréable entre un mode de pensée objet lorsque je fais du dev et un mode de pensée relationnel lorsque je vais fouiller dans les tables. Ben oui désolé mais j'ai encore besoin d'aller voir dans les tables si mes prog font bien ce qu'il doivent faire et je n'ai rien trouvé de mieux que Toad pour le faire.
- le HQL : Même si Hibernate permet d'utiliser du SQL natif, je n'en vois pas l'intéret. Autant utiliser JDBC dans ce cas. Pour moi, Hibernate s'utilise avec HQL. Hors HQL n'a pas tout la souplesse du SQL. Il n'est par exemple pas possible d'utiliser de sous requetes dans la clause From. Dommage.
- l'abstraction de la base de donnée : Hibernate rajoute une couche d'abstraction. Du coup j'ai l'impression que puisque l'on ne s'occupe plus de savoir quelle base de donnée on utilise, on utilise plus les spécificités de la base de données. Du coup, j'ai constaté que les personnes qui utilisaient Hibernate depuis pas mal de temps laissaient tomber les fonctions spécifiques du SGBDR (Oracle dans mon cas). Adieux Decode, NVL et pseudo colonnes. C'est dommage je trouve de ne pas profiter de ce genre de fonctionnalités.... Pire encore, on en arrive à une situation où on se préocupe plus de savoir comment fonctionne un SGBDR. J'ai ainsi pu voir sur ce forum même 2 messages qui font froid dans le dos. 2 personnages ont eu le même problème, à savoir un mapping qui ne fonctionnait pas sur une table sans clé primaire.... Une table sans clé primaire.... Moi ca me fait bondir.....
Bref, cela plus d'autres petites choses que je ne vais pas aborder ici car il faut bien que je finisse, font que je n'aime pas du tout ce framework et que je me pose la question de son utilité.... C'est ca...A quoi ca sert Hibernate? Je vous pose donc la question. Pourquoi l'utilisez vous? Que faites vous avec ce framework que vous ne pourriez pas faire sans?
Moi j'avoue qu'un JDBC avec le pattern DAO et dbutils suffisent largement à mon bonheur. J'ai quelque chose de simple, robuste, efficate et évolutif....
PS : ceci n'est pas un troll. ;)
J'étais moi aussi réticent avant d'utiliser Hibernate, mais maintenant, je ne pourrais plus m'en passer.
Je trouve beaucoup plus agréable, lisible et maintenable de développer en objet.
Ca ne me dérange pas plus que ça de penser objet dans le code, et penser
relationnel quand j'ai besoin de regarder les données dans la base.
C'est une question d'habitude.
Pour ce qui est des spécificités des bases, tu n'as qu'à utiliser du SQL pur
pour les cas où tu en as besoin.
HQL a jusqu'à présent couvert mes besoins.
L'intérêt est quand même de pouvoir changer de base facilement.
Comme cela a été dit plus haut, Hibernate permet d'utiliser facilement un système de cache, de pool de connexions, etc...
Je ne vois pas comment on peut préférer faire du JDBC pur...
Pour ma part, je vais également affirmer l'utilité d'Hibernate dans un projet. En effet, au delà d'un simple framework de persistance, c'est aussi et surtout un outil d'économie de code. En effet, si tu tiens à aller dans les comparaisons d'efficacité et de souplesse, je peux te confirmer que JDBC est également plus rapide en exécution qu'Hibernate (normal, il en est une surcouche après tout !). Alors pourquoi utiliser Hibernate ?
Et bien pour des raisons de maintenabilité par exemple, imagine toi changer tes 3000 requetes (grosse appli dira-t-on) car ta nouvelle base de données ne supporte pas certaines fonctions ("is null" par exemple) alors qu'hibernate t'apporte justement cette souplesse de ne modifier que le fichier de properties. Bien évidemment, on ne change pas de support BDD tous les quatre matins mais ce risque doit être mesuré.
D'un point de vue développement, personnellement, j'ai trouvé Hibernate très agréable à l'utilisation, mis en place sous forme de service ou bien à l'aide d'un pattern DAO. Le point fort repose surtout, selon moi, sur la non utilisation de langage de requêtage justement. Certes HQL existe, mais l'API criteria permet de s'en passer dans de nombreux cas, voire quasi tous en ce qui me concerne. Et les rares soucis que j'ai eu avec Criteria n'ont pas pu être exécutés en HQL (donc SQLQuery oblige). J'y ajouterai les triggers applicatifs, les listeners et tout ce qui s'en suit qui te permettent ainsi de te détacher complétement de la base de données.
Pour ce qui touche au mapping o/r, le but est justmeent ici d'éloigner le développement d'un raisonnement relationnel pour ne penser plus qu'objet dans son développement. Ainsi, on parle bien de récupérer les objets O et non plus les lignes X,Y,Z des tables A,B,C via une jointure externe sur les colonnes P,Q et R.
Enfin, j'irai même jusqu'à parler d'assistance au développement avec une facilité accrue de connexion d'outils pour les pools de connexion, les transactions, etc. (bref, les frameworks en rapport avec la base de données).
Voila mon point de vue, en espérant t'apporter une vision différente de la tienne (mais tout aussi intéressante :roll:). ;)
Bonjour, j'utilise Hibernate pour palier à une situation vraiment todue (et oui, nicgando, contrairement à toi, j'utilise hibernate pour me sortir des situation todue) à laquelle je ne peut rien changer, et à ma connaissance il est un des seul à pouvoir s'en sortie de manière élégante.Citation:
Envoyé par Pitivier
J'ai un CMS (Content Management System), qui génère tout le shéma de la base de données, ma base de données n'est pas relationelle (aucune clé étrangère, pas de liaison entre les tables, tables quasiment 'plate'), les noms de tables et de colonnes généré par le CMS peuvent dépasser la taille standard de 32 charactère, dans ce cas là, le CMS utilise une table de concordance nom long/nom court. Mais hélas, ces nom court peuvent changer entre deux redéployement de tables (rare mais ça arrive). En gros, j'avais besion d'un framework permettant de faire de l'objet sur une table même pas relationelle (donc permettant de créer lui-même le coté relationel) et permettant de remapper à la volé les nom de table/colonne.
Hibernate peut le faire :
- Utilisation des component pour mapper une table en plusieurs object
- Utilisation d'une NamingStrategy pour mapper à la volé nom de colonnes et nom de table.
Je passe sur plein d'autre avantages qu'a hibernate, mais c'est claire que ses fonctionnalité trés avancé de mapping sont vraiment la raison de sa popularité
Petite précision, HQL supporte les sous requêtes, et ce depuis un bon moment, au moins depuis la 3.0.5.
Sous-requête HQL possible en 2.1.6
Par contre, je n'ai jamais essayé de sous-requête dans la clause FROM (mais de toute façon tout les SGBD ne le supporte pas donc il vaut mieux ne pas l'utiliser sinon on n'est plus indépendant du SGBD et on perd tout l'interet d'hibernate)
Autant pour moi, je n'avais pas tilté qu'il était question de sous requêtes dans la clause from.
Je suis assez d'accord avec toi sur ce point. La logique voudrait qu'Hibernate puisse s'utiliser sans langage de requetage, qu'on ne fasse que manipuler des objets.Citation:
Envoyé par BizuR
Criteria ou HQL, même combat, c'est juste une façon d'écrire différente.
HQL est certes un langage de requête, mais "objet".
Selon la complexité, je trouve HQL plus lisible.
Et puis comment récupérer des données sans requête ?