Quand est-il favorable d'utiliser JPA ?

Bonsoir,
D'habitude j'utilise toujours le mapping JPA avec Hibernate dans le développement web, et cette fois, il s'agit d'un développement d'application JAVA avec Swing et aussi JADE (développement agents) . En réfléchissant sur comment mieux faire mon programme, je me suis demandée quand est il favorable d'utiliser un outil de mapping/persistance comme JPA? et quand c'est non nécessaire (compliquer le travail pour rien) ? Quelqu'un pourra-t-il m'aider en répondant à ces questions?
Dans mon programme, j'ai des multitudes de transactions avec la base de données (qui contient plusieurs tables et parfois des jointures entres trois tables)
Merci

bonjour,

Citation:

---

Envoyé par janyoura

En réfléchissant sur comment mieux faire mon programme, je me suis demandée quand est il favorable d'utiliser un outil de mapping/persistance comme JPA? et quand c'est non nécessaire (compliquer le travail pour rien) ?

---

En fait, tu dis que JPA te complique le travail, alors qu'il fait l'inverse .... tu n'as pas a gérer les connexions et le mapping bd/objet !
Dans une application web en plus tu ne gère même pas les transactions, ce que tu dois effectivement faire dans une application qui ne s'exécute pas dans un conteneur.

En quoi trouves tu JPA plus compliqué, que de faire du JDBC classique ?

@janyoura

Citation:

---

En réfléchissant sur comment mieux faire mon programme, je me suis demandée quand est il favorable d'utiliser un outil de mapping/persistance comme JPA? et quand c'est non nécessaire (compliquer le travail pour rien) ?

---

JPA c'est pratique quand tu mets en place un site web, pour une application Swing un peu moins mais ça peut le faire. Par contre, que ce soit pour l'un ou l'autre des cas cités, si c'est pour mettre en place des requêtes de sélection SQL complexes (ex: sortir des statistiques), JPA ça va pas trop le faire.

Citation:

---

Envoyé par Alkhan

tu n'as pas a gérer les connexions et le mapping bd/objet !

---

Il faut bien sur mettre en place son datasource (avec l'hote, le user etc...). Il faut aussi créer les classes Entity, à l'image des tables dans la base.

Citation:

---

Envoyé par Gugelhupf

Il faut bien sur mettre en place son datasource (avec l'hote, le user etc...).

---

ce que je voulais dire, c'est que tu mes ces informations dans le persistence.xml et ensuite c'est le framework qui gère les connexion et le pool de connexion !
Et cela fait donc moins de choses a géré que lorsque tu fais du jdbc classique.

Citation:

---

Envoyé par Gugelhupf

Il faut aussi créer les classes Entity, à l'image des tables dans la base.

---

Bien sur, mais le générateur dans eclipse fait ça très rapidement, même si c'est pas parfais et qu'il faut faire quelque ajustement à la main. De plus même avec JDBC tu peux très bien avoir des classes pour récupérer les données du ResultSet, ce qui en revient a avoir la même quantité de travaille.
ce que je voulais dire surtout c'est que il ne reste plus qu'a créer les requêtes et ensuite c'est une fois de plus le framework qui gère le mapping entity/table, tu n'a plus besoin de parcourir les resultsets et faire le mapping avec tes objets !

Citation:

---

Envoyé par Alkhan

ce que je voulais dire, c'est que tu mes ces informations dans le persistence.xml et ensuite c'est le framework qui gère les connexion et le pool de connexion !

---

Cela aurait été tellement cool si c'était le cas pour le mode Java EE, mais ce que tu dis là ne s'applique que pour le mode Java SE (d'après mes recherches). Pour le mode Java EE, il faut configurer le datasource à partir d'un fichier externe, puis indiquer dans la balise <jta-data-source> du fichier persistence.xml le nom du datasource.

J'ai créé un topic avec des questions sur JPA, si peux m'aider n'hésite pas :ccool:

Citation:

---

Envoyé par Gugelhupf

Cela aurait été tellement cool si c'était le cas pour le mode Java EE, mais ce que tu dis là ne s'applique que pour le mode Java SE (d'après mes recherches). Pour le mode Java EE, il faut configurer le datasource à partir d'un fichier externe, puis indiquer dans la balise <jta-data-source> du fichier persistence.xml le nom du datasource.

---

Et bien selon moi ce que tu viens de dire n'est pas complètement vrai. Effectivement lorque tu déploie ton application dans un conteneur, tu peux demander a celui ci de géré les transaction mais concrètement rien ne t'y oblige.
Il suffit de mettre <transaction-type="RESOURCE_LOCAL"> dans le persistence-unit et du coup tu gères les transactions comme en java SE !

NB : je vais faire une réponse un peu plus complète dans ton sujet :D

Bonjour,

Il est peut-être possible de préciser la configuration (hote, user etc) dans le fichier persistence.xml en Java EE dans le cas du mode RESOURCE_LOCAL (pas essayé), MAIS on perd tout le bonus apporté par JTA : en mode JTA on écrit au moins 3 fois mois de code, et c'est vraiment dommage qu'on ne puisse pas faire de même en Java SE (avec lequel JTA semble ne pas être compatible).

Merci pour ton aide :ccool:

L'argument JPA évite d'avoir à écrire du code pour l'acquisition d'une connexion et la transaction ne va pas bien loin, on peut très facilement faire le même boulot avec une petite classe utilitaire... Dans la version plus élaborée, on fera une couche DAO...

Pour en revenir à la question de base, je dirais que tout ce qui concerne les requêtes de recherches avec des critères multiples et optionnels, JDBC reste largement (à mon sens) plus simple que JPA (et il ne faut pas perdre de vue l'aspect volumétrique des données rapatriées pour souvent aucun usage).
Pour l'aspect création / mise à jour de tables, là, le système à base d'entity est vraiment sympa, avec la possibilité de cascader les opérations etc...

Il faut également prendre en compte un élément dans le choix : la base de données est-elle fixée une fois pour toute ou on est dans le cas d'un progiciel qui sera déployé sur telle ou telle base. Dans ce deuxième cas, JPA prend tout son sens avec son mapping externe.

JPA est utilisé si tu devras par exemple déployer ton projet dans des SGBD différents plutard.
Si tu as une multitude de table donc il est plus aisé de manipuler des classes pour faire des opérations crud.
Pour ton projet pour moins de 10 table une connexion JDBC sera bien plus rapide. Mais là tu devras perdre par exemple la notion de cascade et de navigation que te donnes JPA.
Par contre avec JPA il faut faire attention au Mapping qui est un sacré piège avec la multitude des selects pour des relations EAGER.
Pour moi depuis que j'utilise JPA/Hibernate je suis plus productif en swing comme en web.