4. Opération de persistance en façade

4.1. Introduction

Pour le moment notre façade ne fait pas grand chose de plus que dans l'exemple préliminaire de ce chapitre. Nous allons donc enrichir ses fonctionnalités, et exposer des fonctions de persistance pour notre modèle.

4.2. Enrichissement du service

On souhaite enrichir notre service de deux manières :

Faire en sorte que notre méthode createMarin crée bien un Marin, plutôt que de retourner -1 systématiquement (ça sera plus utile !).
Ajouter deux méthodes : findMarinById(long) et getAllMarins(), qui retournent respectivement le marin dont on a donné la clé primaire, et la liste de tous les marins en base.

Nous avons déjà écrit du code de création d'entités JPA dans le chapitre précédent. Ce code est juste un appel à la méthode entityMananger.persist(), dans une transaction que nous avons gérée manuellement. Dans un serveur d'applications, les choses ne se déroulent pas tout à fait de la même manière. Tout d'abord, comme nous l'avons entrevu sur notre unité de persistance, les transactions ne sont plus gérées par notre code, mais par le serveur directement. Dans son comportement par défaut, lorsque nous entrons dans une méthode d'un EJB (on appelle ces méthodes des business methods , ou méthode métier), le serveur d'application a ouvert une transaction pour nous. Lorsque l'on quitte cette méthode, le serveur tente de valider cette transaction, sans que nous n'ayons rien à faire. Si cette validation échoue, alors une exception est générée. De plus, l' entity manager que l'on utilise est fourni par le serveur d'applications, en tant que dépendance injectée. Ce mécanisme d'injection de dépendances nous permet de nous affranchir complètement de la création de nombre d'objets techniques. Voyons ces deux points sur l'exemple de notre EJB.

Exemple 62. Injection de l' entity manager dans un EJB

@Stateless(mappedName="MarinService")
 @Remote(MarinService.class)
 public  class MarinServiceImpl  implements MarinService {
    
     // création et injection d'un entity manager associé à  
     // l'unité de persistance nommée cours-ear-pu
     @PersistenceContext(unitName="cours-ear-pu")
     private EntityManager em ;

     @Override
     public  long createMarin(String nom) {

        Marin marin =  new Marin() ;
        marin.setNom(nom) ;
        em.persist(marin) ;

         return marin.getId() ;
    }
}

Cet exemple simple illustre ces deux concepts. Tout d'abord l'injection d'un entity manager : il suffit d'annoter une variable de type EntityManager avec @PersistenceContext. Cette annotation prend en attribut le nom de l'unité de persistance à laquelle cet entity manager est attaché. Ce nom doit donc être le même que celui que l'on a défini dans notre fichier persistence.xml. À chaque fois que notre méthode createMarin(String) sera appelée, le serveur d'applications créera un nouvel entity manager , que nous pourrons utiliser directement. On voit aussi que le code de gestion de la transaction a disparu : cette gestion est prise en charge par le serveur d'applications. En fait, appeler la méthode entityManager.getTransaction() jettera même une exception : lorsque nous sommes dans ce contexte, il n'est pas autorisé de tenter d'accéder à cette transaction. Ce mécanisme d'injection de dépendances est apparu en JEE5, et il est massivement utilisé en JEE6. Il peut paraître un peu choquant au premier abord : nulle part on n'initialise cette variable em dans notre code, ce n'est qu'au moment de son utilisation qu'elle est initialisée par le serveur d'applications.

4.3. Création de la méthode `findMarinById(long)`

Une fois ce squelette d'application en place, il est très facile d'ajouter des méthodes à notre EJB. La première que l'on se propose d'écrire retrouve un marin dont on passe la clé primaire en paramètre. Une fois cette méthode ajoutée à l'interface de MarinService, il nous faut créer son implémentation dans MarinServiceImpl.

Exemple 63. Ajout de la méthode findMarinById(long)

@Override
 public Marin findMarinById(long id) {

    Marin marin = em.find(Marin.class, id) ;
     return marin ;
}

Le principe d'écriture de cette méthode est le même que la précédente : on sait que l' entity manager est créé pour nous, donc on l'utilise de la même façon que dans les exemples du chapitre précédent. Notons que, suivant ce qui a été expliqué sur la gestion des transactions, cette requête crée un objet attaché à la transaction. C'est un peu dommage, puisqu'aucune modification n'est faite dessus. On paye ici un surcoût inutile, ce qui, dans une application d'entreprise n'est jamais une bonne idée. Nous verrons dans la suite comment il est possible de contrôler ce point dans un EJB.

4.4. Ajout de la méthode `findAllMarins()`

Pour cette dernière méthode, on peut ajouter une requête nommée à notre classe Marin.

Exemple 64. Création d'une requête nommée sur la classe Marin

@NamedQueries({
    @NamedQuery(
        name="Marin.findAll",
        query="select marin from Marin marin")
})
 @Entity
 public  class Marin  implements Serializable {

     // reste de la classe
}

Une fois cette requête nommée créée, on peut l'utiliser normalement. Écrivons la méthode findAllMarins() de notre EJB.

Exemple 65. Utilisation d'une requête nommée dans un EJB

@Override
 public List<Marin> findAllMarins() {

    Query query = em.createNamedQuery("Marin.findAll") ;

    List<Marin> marins = query.getResultList() ;
     return marins ;
}

4.5. Utilisation dans un code client

On peut donc maintenant enrichir le code de notre application cliente.

Exemple 66. Code de l'application cliente

public  static  void main(String... args)  throws NamingException {

     // connexion à l'annuaire de notre serveur d'application
     // ne pas oublier le fichier jndi.properties !
    InitialContext context =  new InitialContext() ;

     // requête sur l'annuaire : récupération d'une référence sur notre EJB
    MarinService marinService = (MarinService)context.lookup("MarinService") ;
    
     // utilisation de cet EJB
     long id = marinService.createMarin("Surcouf") ;
    System.out.println("Id = " + id) ;

    Marin marin = marinService.findMarinById(id) ;
    System.out.println("Marin = " + marin) ;

    List<Marin>marins = marinService.findAllMarins() ;
     for (Marin m : marins) {
        System.out.println("Marin = " + m) ;
    }
}

Notons que l'exécution de ce code client est indépendante de l'exécution de notre EJB. Cet EJB est en fonctionnement permanent, à la différence du code client, qui s'éteint une fois que la méthode main() a quitté. Or la base ne se réinitialise qu'au démarrage de notre unité de persistance, qui est maintenant attachée à l'application entreprise. Donc, si l'on lance notre client plusieurs fois de suite, on verra autant de marins "Surcouf" créés en base. Notons enfin, que Netbeans a une bonne capacité à rafraîchir en temps réel l'application entreprise déployée, que le simple fait de modifier la classe Marin, ou notre EJB, peut entraîner immédiatement le redéploiement de cette application.

JPA & EJB

Retour au blog Java le soir

Cours & Tutoriaux