Discussion :

[Wookai]

Salut à tous !

Par ce titre quelque peu énigmatique, j'espère attirer quelques développeurs qui pourront éclairer ma lanterne ! Je me lance dans Hibernate, et après avoir lu un peu la doc et quelques tutoriaux, je me rends compte qu'il y a deux approches :

1. L'écriture du code Java correspondant aux objets que l'on souhaite manipuler dans notre application, pour ensuite laisser Hibernate créer et gérer la base de données
2. La création de la base de données selon ses besoins, puis la génération du code pour l'interfacer avec Hibernate

Personnellement, la 2ème approche me correspondrait mieux, dans le sens où, pour mon projet actuel, j'ai une bonne vision de la structure de ma base de données, et un peu moins de la manière de le représenter directement via des objets Java. En fait, c'est surtout les relations entre ces objets que j'ai de la peine à voir comment implémenter...

Cependant, je comprends bien qu'écrire directement les objets qu'on voudra manipuler et ensuite laisser Hibernate s'occuper de comment le stocker est plus logique d'un point de vue conceptuel : on réfléchit directement en terme d'objets, sans se soucier de la "couche physique".

Qu'en pensez-vous ? Quelle est l'approche généralement utilisée ? Ou alors, suis-je complètement à côté ?

Merci d'avance de vos réponses !

[KneXtasY]

1. La création de la base de données selon ses besoins, puis la génération du code pour l'interfacer avec Hibernate

En gros le problème, c'est est ce qu'on part du bas (le socle) vers le haut (les classes) ou du haut vers le bas ?

Personnellement, je préfère partir de la base et générer mes classes, ça me parait plus logique.

Après pour ce qui ce fait généralement, j'en n'ai pas la moindre idée ...

[fr1man]

Quant à moi, je préfère partir d'un diagramme de classes, puis générer la base de données.
Au moins, tu penses objet de bout en bout.

[Wookai]

C'est clair que penser objet du bout en bout me parait mieux, mais certaines choses me semblent plus simples à modéliser directement dans la base de données...

[MooGle]

Salut,
Moi je dirai le fermier...
L'approche est plus au moins identique car le but de hibernate est de pouvoir decorreller la persistance du model de domaine. En general les deux models auront des differences.
De toute facon pour faire le model de la base ou du domaine il faut bien avoir un premier model qui servira de base...

[Wookai]

C'est clair, au final les différences ne sont que subitilités. Etant un peu plus expérimenté dans le design de base de données, j'ai opté pour cette solution. J'ai ensuite généré les objets à l'aide de Hibernate Tools !

Merci pour vos réponses !

[K-Kaï]

Personnellement, je dirais qu'il faut bien tout de même mettre son nez dans les deux parties (la base de données et les classes DAO).

En effet, il arrive que l'on souhaite voir réagir un peu differemment son code ou architecture de base de données pour répondre à des contraintes bien précises.
Donc la génération automatique est selon moi a utiliser mais pas trop les yeux fermer genre :" Ouais ouais t' inquietes pas ca marche ca a été généré automatiquement".

Pour progresser je dirais pars sur la génération auto de ce que tu connais le mieux, soit la base soit les classes et rédige ce que tu gère le moins, ainsi de ton oeil expert tu peux vérifier ce qu'il a générer et l'adapter et tu progresse sur la parti qui te faisait un peu plus défaut.

Enfin tout ca c'est bien quand on a le temps ce qui je reconnais n'est pas toujours le cas ...

[Wookai]

Je suis d'accord que c'est bien de savoir comment chaque partie fonctionne, et, dans mon cas, vu que je suis plus habitué au design de la base de donnée, je pourrais laisser le soin à mon outil de la générer à ma place, pour me concentrer sur l'objet.

Cependant, dans le cas d'une DAO, il y a quand même des opérations (CRUD) qui sont extrêmement répétitives et pas spécialement intéressantes, je suis donc content que ça soit généré pour ma vingtaine de classes. De plus, l'outil que j'utilise me permet de générer une base de la DAO, qui est générée, et un squelette qui étend la base et que je peux remplir à ma convenance, si je veux ajouter des méthodes. Ainsi, mes ajouts ne sont pas écrasés lorsque je régénère le tout.

Et comme tu l'as dit, c'est aussi une question de temps. Pour ce projet, je suis un peu limite, je vais donc essayer de gagner le plus de temps possible en générant les choses "répétitives" !

[K-Kaï]

Pour la répétitivité je suis entièrement d'accord avec toi, rien de plus ennuyeux que de se taper 20 fois l'ajout d'un élément tout simple etc etc ...

Je voyais plus le coté gaffe à la génération au niveau des héritages, gestion du lazy loading ...

Sinon tu peux (si ce n'est pas secret) indiquer le nom de ton plug in qui te permets de générer ce que tu indiques.

Enfin je penses que nous seront tous d'accord, trouver un plug in qui génère des choses propres (XML, Classe, schema de BDD) et quand même jeter un oeil qur ce qui a été fait ...
Et le plus important ensuite le maitriser ce plug parce que c'est fou comment un outil que l'on aurait pu penser bof au premier abord peut se révéler redoutable quand on a compris complètement son fonctionnement.

[Wookai]

Ce n'est pas secret du tout !

Au début, j'ai utilisé le plugin "officiel" pour Eclipse, à savoir Hibernate Tools. Il permet de faire pas mal de choses, ajoute notamment une vue "console" qui permet de faire des requêtes HQL, etc... Au niveaud de la génération du code, il permet de le faire dans les deux sens, soit depuis les POJOs pour créer les fichiers de mapping et générer le schéma de la DB, soit depuis la DB pour générer les POJOs (avec syntaxe java 5 ou non, avec annotations EJB3 ou non), les fichiers de mapping et même la config ! Il peut aussi générer une DAO basique et des rapports.

Je n'étais pas très satisfait de la DAO (malgré la possiblité très puissante d'utiliser ses propres templates pour tout le code généré, des POJOs à la DAO ! Je n'ai malheureusement pas trouvé bcp de doc à ce sujet), alors j'ai commencé à regarder ce que je trouvais d'autre ! Et je suis tombé sur Hibernate Synchronizer, qui fait exactement ce que je veux !

Il permet de générer des fichiers de mapping à partir de la DB. Ensuite, à partir de ces fichiers de mapping, on peut générer les POJOs et la DAO (pour générer la DAO, il faut modifier une option dans les fichiers de mapping générés, mettre l'option sync-DAO à true au lieu de false), et le tout avec des classes "base" qui sont écrasées à chaque génération, et des classes customisable qu'on peut modifier et qui ne sont pas écrasée (très pratique pour la DAO !). Bien sûr, pas mal de choses sont configurables : lazy loading ou non, package, generics ou non, etc...

Et ce qui est génial, c'est qu'on peut à tout moment, par un simple clic droit sur les fichiers de mapping, demander au plugin de les re-synchroniser avec la base de données, ce qui a pour effet de regénérer les POJOs et la DAO associée !

Bref, le rêve je trouve ! Et comme tu l'as si bien dit, c'est important d'explorer à fond un plugin ! J'y avais jeté un oeil, mais n'avais pas vu toutes ses possibilités, et l'avais désinstallé !