Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

4INFOB2/3 ZK Page 1 Langage orienté objet et persistance En Java, nous manipulo

4INFOB2/3 ZK Page 1 Langage orienté objet et persistance En Java, nous manipulons des objets qui sont des instances de classes ; les objets héritent les uns des autres, peuvent utiliser des collections d'autres objets et, parfois, se désignent eux-mêmes de façon récursive. Nous disposons de classes concrètes, de classes abstraites, d'interfaces, d'énumérations, d'annotations, de méthodes, d'attributs, etc. Cependant, bien que les objets encapsulent soigneusement leur état et leur comportement, cet état n'est accessible que lorsque la machine virtuelle (JVM) s'exécute : lorsqu'elle s'arrête ou que le ramasse- miettes nettoie la mémoire, tout disparaît. Ceci dit, certains objets n'ont pas besoin d'être persistants. Par données persistantes, nous désignons les données qui sont délibérément stockées de façon permanente sur un support magnétique, une mémoire flash, etc. Un objet est persistant s'il peut stocker son état afin de pouvoir le réutiliser par la suite. La sérialisation: Il existe différent moyens de faire persister l'état en Java. L'un d'eux consiste à utiliser le mécanisme de sérialisation qui consiste à convertir un objet en une suite de bits : nous pouvons ainsi sérialiser les objets sur disque, sur une connexion réseau (notamment Internet), sous un format indépendant des systèmes d'exploitation. Java fournit un mécanisme simple, transparent et standard de sérialisation des objets via l'implémentation de l'interface java.io.Serializable. JDBC Un autre moyen de mémoriser l'état consiste à utiliser JDBC (Java Database Connectivity), qui est l'API standard pour accéder aux bases de données relationnelles. Nous pouvons ainsi nous connecter à une base et exécuter des requêtes SQL (Structured Query Language) pour récupérer un résultat. Cette API fait partie de la plate-forme Java depuis la version 1.1 mais, bien qu'elle soit toujours très utilisée, elle a tendance à être désormais éclipsée par les outils de correspondance entre modèle objet et modèle relationnel (ORM, Object-Relational Mapping), plus puissant. -L'utilisation pour la persistance d'un mapping O/R permet de proposer un niveau d'abstraction plus élevé que la simple utilisation de JDBC : ce mapping permet d'assurer la transformation d'objets vers la base de données et vice versa que cela soit pour des lectures ou des mises à jour (création, modification ou suppression). -Développée dans le cadre de la version 3.0 des EJB, cette API ne se limite pas aux EJB puisqu'elle peut aussi être mise en oeuvre dans des applications Java SE. -L'utilisation de l'API ne requiert aucune ligne de code mettant en oeuvre l'API JDBC. -L'API propose un langage d'interrogation similaire à SQL mais utilisant des objets plutôt que des entités relationnelles de la base de données. -L'API Java Persistence repose sur des entités qui sont de simples POJOs annotés et sur un gestionnaire de ces entités (EntityManager) qui propose des fonctionnalités pour les manipuler (ajout, modification suppression, recherche). Ce gestionnaire est responsable de la gestion de l'état des entités et de leur persistance dans la base de données. -Comme pour JDBC, l’utilisation de JPA nécessite un fournisseur de persistance qui implémente les classes et méthodes de l’API Exemple d'implémentation: Hibernate,EclipseLink... 4INFOB2/3 ZK Page 2 Entité: Une entité JPA est, par définition, une classe Java annoté par (@Entity) qui doit avoir les propriétés suivantes :  Elle doit posséder un constructeur vide, public ou protected. Rappelons que ce constructeur vide existe par défaut si aucun constructeur n'existe dans la classe. Dans le cas contraire, il doit être ajouté explicitement.  Elle ne doit pas être final, et aucune de ses méthodes ne peut être final.  Une entité JPA ne peut pas être une interface ou une énumération.  Une entité JPA peut être une classe concrète ou abstraite.  Si une instance d’entité doit être passée par valeur sous forme d’objet detache(via une interface distante, par exemple), la classe de l’entité doit implémenté l’interface Serializable.  Elle doit posséder un attribut qui représente la clé primaire dans la BD (@Id)  Le fournisseur de persistance accédera à la valeur d’une variable d’instance: -Soit en accédant directement à la variable d’instance -Soit en passant par ses accesseurs (getter ou setter)  Le type d’accès est déterminé par l’emplacement de l'annotation @Id (associées aux variables d’instance ou aux getter)  Le choix doit être le même pour toutes les classes d’une hiérarchie d’héritage (interdit de mélanger les 2 façons)  En programmation objet il est conseillé d’utiliser plutôt les accesseurs que les accès directs aux champs (meilleur contrôle des valeurs) ; c’est aussi le cas avec JPA Rappel : le choix est déterminé par l'emplacement des annotations ; elles sont associées soit aux accesseurs, soit aux variables d'instance ; ne pas mélanger les 2 ! 4INFOB2/3 ZK Page 3 Exemple d'entité: 1-Tout d'abord, la classe est annotée @javax.persistence.Entity, ce qui permet au fournisseur de persistance de la reconnaître comme une classe persistante et non comme une simple classe POJO. 2. Puis l'annotation @javax.persistence.Id définit l'identifiant unique de l'objet. JPA étant destiné à associer des objets à des tables relationnelles, les objets doivent posséder un identifiant qui sera associé à une clé primaire. A retenir : Une entité doit impérativement posséder un attribut dont la valeur est unique, dit identificateur unique ou clé primaire. Ce champ permet de différencier chaque objet entité des autres. Cette clé primaire doit être définie une seule fois dans toute la hiérarchie de l'entité. Lorsque nous créons une entité, la valeur de cet identifiant peut être produite manuellement par l'application, ou automatiquement par le fournisseur de persistance si nous précisons l'annotation @GeneratedValue. Celle-ci peut accepter l'une des quatre valeurs suivantes : 1. IDENTITY : Ce type indique au fournisseur de persistance d'assigner la valeur de la clé primaire en utilisant la colonne identité de la base de données. Sous MySQL, par exemple, la clé primaire auto- générée est marquée avec AUTO_INCREMENT 2SEQUENCE : Ce type, comme son nom l'indique, oblige le fournisseur de persistance à utiliser une séquence de la base de données. 3. TABLE : Ce type demande au fournisseur de persistance de stocker le nom de la séquence et sa valeur courante dans une table et d'incrémenter cette valeur à chaque fois qu'une nouvelle instance de l'entité est stockée dans la base. Configuration « par exception » La configuration des classes entités suppose des valeurs par défaut • Il n’est nécessaire d’ajouter des informations de configuration que si ces valeurs par défaut ne conviennent pas • Par exemple, @Entity suppose que la table qui contient les données des instances de la classe a le même nom que la classe Mapping Objet/Relationnel 4INFOB2/3 ZK Page 4 Nom de Table: Pour donner à la table un autre nom que le nom de la classe, il faut ajouter une annotation @Table Nom de Colonne: Pour donner à une colonne de la table un autre nom que le nom de l’attribut correspondant, il faut ajouter une annotation @Column Classe Embeddable Les entités persistantes ne sont pas les seules classes persistantes. Il existe aussi des classes « insérées » ou « incorporées » (embedded) dont les données n’ont pas d’identité dans la BD mais sont insérées dans une des tables associées à une entité persistante -Elles peuvent être annotées comme les entités (avec @Column par exemple) - Par exemple, une classe Adresse dont les valeurs sont insérées dans la table Employe -Comme les entités, ces classes doivent avoir un constructeur sans paramètre -Les types permis pour leurs attributs sont les mêmes que les types permis pour les attributs des entités. Mapping Objet/Relationnel Mapping Objet/Relationnel 4INFOB2/3 ZK Page 5 Clé composite: Pas recommandé, mais une clé primaire peut être composée de plusieurs colonnes • Peut arriver quand la BD existe déjà ou quand la classe correspond à une table association (association M:N avec information ) • 2 possibilités : -@IdClass -@EmbeddedId et @Embeddable Dans les 2 cas, la clé primaire doit être représentée par une classe Java dont les attributs correspondent aux composants de la clé primaire • La classe doit être public, posséder un constructeur sans paramètre, être sérialisable et redéfinir equals et hashcode. IdClass -@IdClass correspond au cas où la classe entité comprend plusieurs attributs annotés par @Id La classe entité est annotée par @IdClass qui prend en paramètre le nom de la classe clé primaire -La classe clé primaire n’est pas annotée (comme @Embeddable) ; ses attributs ont les mêmes noms et mêmes types que les attributs annotés @Id dans la classe entité EmbeddedId: @EmbeddedId correspond au cas où la classe entité comprend un seul attribut annoté @EmbeddedId • La classe clé primaire est annoté par @Embeddable 4INFOB2/3 ZK Page 6 Associations -Il s'avère qu'une entité ne travaille généralement pas seule mais qu'elle est reliée à d'autres entités. On parle de relations entre entités. Cela correspond, bien entendu, à une base de données relationnelle où les tables sont effectivement en relations les unes avec les autres. -Une relation possède une direction. Elle peut être unidirectionnelle (un objet peut utiliser un autre objet) ou bidirectionnelle (un objet peut interroger un autre objet et vice versa). En Java, nous utilisons le point (.) pour naviguer entre les objets. Ainsi, lorsque nous écrivons, par exemple : client.getAdresse().getPays(); nous navigons d'un uploads/s3/03-jpa.pdf