Discussion :

[Baptiste Wicht]

Bonjour,

Je suis en train de regarder JPA et c'est génial

Je travaille avec Java SE, donc si je veux utiliser les EJB3, il faut que j'utilise le conteneur standalone de JBoss.

J'ai donc une question à laquelle je n'ai pas vraiment trouvé de réponses : "Quel-est le ou les avantages d'utiliser les EJB3 avec JPA plutôt que de travailler sans ?"

Si quelqu'un a une idée là-dessus, ce serait cool

[djo.mos]

Bonjour.
Il faut savoir que JPA n'est pas exactement EJB 3. JPA est le remplaçant des Entity Beans de l'EJB 2.
Comme principaux avantages parapport aux anciens Entity Beans de l'EJB 2, JPA permet de:
moins de dépendances à une API particulière: plus besoin d'hériter ou d'implémenter une interface ou classe particulière.
Utilisable dans un environnement SE (au lieu de EE uniquement).
Simplicité du mapping: Par exemple, dans JPA, n'importe quel champ d'une classe est implicitement persistent, sans avoir à le spécifier. Au contraire, il faut annoter les champs non persistents avec @Transient.
De plus, les paramètres par défaut des annotations sont en général les bons. càd qu'en général, il suffit juste de mettre l'annotation adaptée pour que ça fonctionne (OneToMany, ManyToMany, etc.) sans avoir à les configurer en détail.
Fortement inspiré d'autres frameworks qui ont fait leurs preuves comme Hibernate. D'ailleurs, Gavin King est l'homme derrière JPA
C'est zolie
Là, c'est un avis perso, je sais qu'il y'a beaucoup de gens qui voient les annotations comme evil (hein KilVaiDen ), mais perso, le gain de temps qu'elles rendent possible, la simplcité du refactoring, leur clarté, etc. m'ont l'air incontournables.

Voilou.

P.S: Je ne suis pas certain d'avoir bien saisi ta question Baptiste.

[Baptiste Wicht]

Merci pour ta réponse

Mais :

P.S: Je ne suis pas certain d'avoir bien saisi ta question Baptiste.

Non pas vraiment

En fait, dans un environnement Java SE, on peut travailler avec JPA avec ou sans EJB. J'aurais aimé savoir quel était l'avantage d'utiliser les EJB ?

Mais ta réponse est très intéressante quand même

[djo.mos]

Ah ok, c'est plus clair maintenant
JPA peut être utilisé indépendamment des EJBs, que ce soit dans un environnement SE ou EE.
En fait, dans l'architecture actuelle de Java, JPA est spécifique à la persistence des données (couche DAO + DTO) tandis que les EJBs servent surtout pour la couche services.

[OButterlin]

Il faut savoir que JPA n'est pas exactement EJB 3. JPA est le remplaçant des Entity Beans de l'EJB 2.

Il ne faut pas confondre EJB3 et JPA... EJB3 Entity (CMP) s'appuie sur un JPA pour la persistence sachant qu'on peut utiliser hibernate, toplink ou un autre JPA...
EJB3 va plus loin que les pojos mais s'il s'agit de se limiter aux Entity, la différence est moindre...
Alors pourquoi utiliser EJB plutôt qu'hibernate (par exemple) ?
-> et bien parce que l'ejb représente une sorte d'abstraction de la persistence, il standardise, et qu'on peut, par la suite, changer de JPA sans avoir à modifier l'ejb ou les facades
Il existe aussi des fonctionnalités très intéressante au niveau des ejb, comme l'appel distant, la notion de role, les méthodes appelées avant/après un événement (beforePersist, afterPersist) etc...

A+

[denisjava]

Arrétons de parler des EJB entités, ils n'existent plus.
La spec ejb3 est scindée en deux:

• ejb session ou mdb
• Java Persistence API

Ceux qui on lu les specs me diront que le terme ejb entités reste utilisé dans la première parti, mais c'est un faux amis... Nous n'avons pus de composants JavaEE : nous avons des pojo (différence énorme à l'origine du succès de produits comme hibernate)

JPA est fortement inspiré par Hibernate et toplink. La preuve: Les core developer d'hibernate ont participé à la rédaction de ces specs.
L'utilisation de JPA est donc gage d'indépendance théorique de votre code vis à vis d'hibernate (ou tout autre orm). Je dis théorique car JPA ne couvre pas ce qui touche au tuning, laissant cette partie aux diverses implémentation de la norme qui vous propose différentes annotations propriétaires pour cela => rendant votre code dépendant :-( (BatchSize par exemple)

Il ne faut pas confondre EJB3 et JPA... EJB3 Entity (CMP) s'appuie sur un JPA pour la persistence sachant qu'on peut utiliser hibernate, toplink ou un autre JPA...
EJB3 va plus loin que les pojos mais s'il s'agit de se limiter aux Entity, la différence est moindre...
Alors pourquoi utiliser EJB plutôt qu'hibernate (par exemple) ?
-> et bien parce que l'ejb représente une sorte d'abstraction de la persistence, il standardise, et qu'on peut, par la suite, changer de JPA sans avoir à modifier l'ejb ou les facades
Il existe aussi des fonctionnalités très intéressante au niveau des ejb, comme l'appel distant, la notion de role, les méthodes appelées avant/après un événement (beforePersist, afterPersist) etc...

A+

[Baptiste Wicht]

Je suis en train de lire un bouquin sur JPA et cette fois, j'ai bien l'avantage des EJB avec JPA.

Cela permet surtout de simplifier la gestion de l'EntityManager grâce aux beans EJB, les exemples donnés dans le livre coule de source.

On délègue une partie du traitement JPA aux EJB, ce qui permet de se concentrer sur la partie importante.