Après le choix de JSF: Adopter JPA ou Hibernate?

Bonjour!

Je suis un débutant dans le développement des applications web, et après avoir effectué le choix de JSF comme framework, j'ai commencé naturellement à chercher des tutoriels pour me familiariser avec la méthodologie adoptée pour développer une application CRUD tel qu'il m'est demandé de réaliser.

D'une part, j'ai trouvé un tutoriel clair et précis sur le site officiel de Netbeans, intitulé Generating a JSF 1.2 CRUD Application from a Database. Dans cet exemple, il y a pour chaque classe entité:

• une classe de contrôle JPA
• une classe de contrôle JSF
• une classe de conversion JSF
• un répertoire contenant les 4 fichiers (detail.jsp, edit.jsp, list.jsp, new.jsp)

Par la suite, l'assistant génère un peu tout, et une simple exécution permet d'avoir tous les résultats des requêtes CRUD. Sauf que le code est très très peu intelligible pour un débutant comme je le suis, l'ajout d'autres fonctionnalités devient donc chimérique.

D'une autre part, un collègue m'a filé un code, où le mapping avec la BD est assuré par Hibernate. En plus du package de classes entités généré par ce dernier, il y a un package de managed beans relatifs à ces classes. Ces dernières contiennent les sessions, les transactions, les query avec des requêtes HQL. Cette solution requiert un effort considérable, est moins automatique que la première, mais demeure largement compréhensible.

Quelle serait la différence entre les deux méthodes? Une application web CRUD peut elle être effectuée des deux façons? Laquelle est meilleure en fin du compte?

Alors, dans un premier temps, il faut savoir que JPA et Hibernate ne s'excluent pas, Hibernate étant une implémentation de JPA.
Il faut voir JPA comme une norme et Hibernate (par exemple) comme une réalisation de cette norme.

La question est plutôt : utiliser la persistence via JPA ou via Hibernate natif.

Personnellement, je te conseille JPA.
L'avantage que j'y vois est que tu peux passer d'une implémentation Hibernate à TopLink sans avoir à modifier ton application.
Au niveau des possibilités, c'est déjà très abouti...
Ceci dit, Hibernate va un peu plus loin sur quelques points... au niveau du tri des collections d'objets liés par exemples.

Au niveau langage de requête, j'ai une petite préférence pour le JPQL (plus proche de SQL) mais le HQL est très bien également. C'est plus une question d'habitude...

Dans les 2 cas, il est bon de découper par couches logiques.
- les entités
- le mapping (si tu n'utilises pas les annotations)
- les DAO

Si tu parts sur EJB3 les DAO sont remplacées par des EJB Stateless/Statefull

Merci pour votre réponse, elle m'apporte quelques clarifications.

Reste une ambiguïté concernant les couches logiques que vous avez cité en fin de votre post. En effet, je ne comprends pas la distinction entre une classe mapping et une classe entité, à mon sens il s'agit de la même chose, càd des classes représentant les tables de la base de données. Lesquelles sont donc la transposition des tables, et lesquelles contiennent les méthodes d'ajout, suppression, ...

Je pensais plus particulièrement au mapping externe, d'où la précision concernant le non usage des annotations.
Avec Hibernate, tu peux choisir entre un fichier de mapping xml ou les annotations.
Dans le premier cas, il est préférable à mon sens d'isoler dans un répertoire/package distinct la configuration.

Sinon, avec annotations, 2 packages genre com.etc.entity et com.etc.dao suffiraient, encore que tu peux structurer comme tu l'entends, il n'y a pas de contraintes à ce niveau.

Merci pour tes explications OButterlin, elles sont claires et riches d'informations.