JPA fait-il partie de EJB 3.0 ?
Oui et non... Oui parce que chaque serveur d'application qui prétend mettre en œuvre la spécification EJB 3.0 doit également fournir une mise en œuvre de JPA. Non car JPA peut être facilement utilisé en dehors d'EJB, dans des applications autonomes ou gérées par Spring.
JPA manipule les Entity Beans ?
Haricots d'entité était une idée effrayante dans les EJBs pré-3.0. JPA utilise le terme entités pour se distinguer de l'histoire déshonorante. Mais oui, les entités JPA sont un moyen de faire correspondre des tables de base de données à des objets Java ordinaires. En principe, les modifications apportées à l'objet sont propagées à la base de données et vice-versa (simplification excessive).
Comme je l'ai dit, JPA ne dépend pas d'EJB (considéré comme un haricot de session avec ou sans état) et vice-versa. Mais rien ne vous empêche d'utiliser JPA dans EJB.
Dans votre scénario, vous avez un EJB sans état qui construit la requête et interagit avec la base de données via JPA. Techniquement parlant, vous appellerez des méthodes sur EntityManager injecté dans votre haricot :
@Stateless
public class SearchService {
@PersistenceContext
private EntityManager em;
public List<User> findUsersBornAfter(Date date) {
return em.
createQuery("SELECT u FROM User u WHERE u.birthDate > :birthDate ORDER BY name").
setParameter("birthDate", date).
getResultList();
}
}
Comme vous pouvez le constater, la couche métier connaît le modèle de données (évidemment), mais il n'y a aucune dépendance vis-à-vis des services EJB/business en ce qui concerne les entités. Dans cet exemple, une requête JPQL est formée dans la couche service et User est une entité JPA. Appeler getResultList() fait en sorte que le fournisseur JPA traduise JPQL en SQL, exécute la requête et retransmette les résultats à l'utilisateur. User instances d'objets.
La frontière entre EJB et JPA est-elle désormais claire ?
