Introduction à Hibernate p.1

« Spread Information Technology »
Athman Hajhamou
Club Informatique-FSDM

Sommaire
I. Modèle MVC : rappel.
II. Architecture.
III. Configuration.
1. Connexions JDBC.
2. Quelques propriétés de configuration optionnelles.
3. Fichier de configuration XML.
IV. Classes persistantes.
V. Mapping O/R basique.
VI. Mapping des associations.
VII. Manipulation d’objets persistants.
VIII.SQL natif.
IX. Requêtes par critères.

MVC
• Une architecture logicielle qui permet de
séparer une application en trois parties :
Le modèle contient les objets applicatifs.
Les vues affiche à l’utilisateur des information sur le modèle.
Le contrôleur agit sur la demande de l’utilisateur et effectue les
actions nécessaire sur le modèle.
Côté applicatif
Côté événementiel
Côté visuel

MVC
traduits
• en changement dans la vue s'ils
agissent sur le côté visuel.
OU
• en changement dans le modèle s'ils
agissent sur le contenu du modèle.
Reçoit les événements de l'interface utilisateur
Contrôleur

MVC
Il peut être modifié sur ordre du contrôleur
Modèle
Il signale à ses vues tout changement de contenu
en leur envoyant un événement qui leur spécifie
de se mettre à jour
Mais il ignore :
• comment il est affiché.
• qui lui a notifié un changement d'état.

MVC
Elle se met à jour dès qu'elle reçoit un ordre de
notification du contrôleur ou du modèle.
Vue
Quand la notification vient du modèle, elle va
consulter le modèle pour se réafficher de
manière adéquate.

Intérêts de l'architecture MVC
Représentation logique d'une
application (modèle)
Représentation visuelle qu’on en donne
(vue)
Actions que l ’utilisateur effectue
(contrôleur)
Indépendance
Modularité dans la conception
•vue et contrôleur peuvent être
développés indépendamment
du modèle (pourvu qu'une
interface entre les deux soit
définie).
Meilleure répartition des tâches
•développeurs du modèle:
connaissance métier
•développeurs de l ’interface :
connaissance des besoins
utilisateurs, souci d ’ergonomie…
MVC

Séparation claire entre les données du programme et
l’interface graphique affichant ces données
Possibilités de vues différentes d'un même modèle
Intérêts de l'architecture MVCMVC

HIBERNATE
Constat
Travailler dans les deux univers que sont l'orienté objet et la base de
données relationnelle peut être lourd et consommateur en temps dans le
monde de l'entreprise d'aujourd'hui.
Solution
Hibernate peut réduire de manière significative le temps de
développement qui aurait été autrement perdu dans une manipulation
manuelle des données via SQL et JDBC. Le but d'Hibernate est de libérer le
développeur de 95 pour cent des tâches de programmation liées à la
Persistance des données communes

Mapping Objet/Relationnel (ORM)
• Le terme mapping objet/relationnel (ORM) décrit la technique
consistant à faire le lien entre la représentation objet des
données et sa représentation relationnelle basée sur un schéma
SQL.
• Hibernate est un outil de mapping objet/relationnel pour le
monde Java. Non seulement, il s'occupe du transfert des classes
Java dans les tables de la base de données (et des types de
données Java dans les types de données SQL), mais il permet
de requêter les données et propose des moyens de les
récupérer.

Première application
• Vous pouvez voir que cette classe utilise les
conventions de nommage standard JavaBean
pour les méthodes getter/setter des propriétés,
ainsi qu'une visibilité privée pour les champs.
• La propriété code contient la valeur d'un
identifiant unique pour un événement
particulier. Toutes les classes d'entités
persistantes (ainsi que les classes dépendantes
de moindre importance) auront besoin d'une
telle propriété identifiante si nous voulons
utiliser l'ensemble complet des fonctionnalités
d'Hibernate.
JavaBean (Employee)

• La méthode setter devrait être privée. Seul
Hibernate assignera les identifiants lorsqu'un
objet est sauvegardé.
• Le constructeur sans argument est requis pour
toutes les classes persistantes; Hibernate doit
créer des objets pour vous en utilisant la
réflexion Java.
JavaBean (Employee)

• Hibernate a besoin de savoir
comment charger et stocker
des objets d'une classe
persistante. C'est là
qu'intervient le fichier de
mapping Hibernate. Le fichier
de mapping indique à
Hibernate à quelle table dans la
base de données il doit
accéder, et quelles colonnes de
cette table il devra utiliser.
Fichier de mapping

• L'élément code est la déclaration de la
propriété de l'identifiant, name="code" déclare
le nom de la propriété Java- Hibernate utilisera
les méthodes getter et setter pour accéder à la
propriété. L'attribut column indique à
Hibernate quelle colonne de la table
EMPLOYEES nous utilisons pour cette clef
primaire. L'élément generator imbriqué
spécifie la stratégie de génération de
l'identifiant ,dans ce cas nous avons utilisé
increment.
Fichier de mapping

Fichier de mapping

• Les types que nous déclarons et utilisons dans
les fichiers de mapping ne sont pas, comme
vous pourriez vous y attendre, des types de
données Java. Ce ne sont pas, non plus, des
types de base de données SQL. Ces types sont
donc appelés des types de mapping Hibernate,
des convertisseurs qui peuvent traduire des
types Java en types SQL et vice versa.
Fichier de mapping

• Nous avons maintenant une classe
persistante et son fichier de mapping. Il
est temps de configurer Hibernate.
• Pour la configuration d'Hibernate, nous
pouvons utiliser un simple fichier
hibernate.properties, un fichier
hibernate.cfg.xml légèrement plus
sophistiqué, ou même une configuration
complète par programmation. La plupart
des utilisateurs préfèrent le fichier de
configuration XML.
Fichier de configuration

• Nous configurons une SessionFactory
d'Hibernate une fabrique globale responsable
d'une base de données particulière. Si vous
avez plusieurs base de données, utilisez
plusieurs configurations <sessionfactory>,
généralement dans des fichiers de configuration
différents (pour un démarrage plus facile).
• Les quatre premiers éléments property
contiennent la configuration nécessaire pour la
connexion JDBC. L'élément property du
dialectes pécifie quelle variante du SQL
Hibernate va générer.

• Nous devons compléter la configuration avec du
code d'infrastructure. Nous devons démarrer
Hibernate. Ce démarrage inclut la construction
d'un objet SessionFactory global et le stocker
quelque part facile d'accès dans le code de
l'application. Une SessionFactory peut ouvrir des
nouvelles Sessions.
• La SessionFactory est un objet global instancié une
seule fois.
• Nous créerons une classe d'aide
HibernateSessionFactory qui s'occupe du
démarrage et rend la gestion des Sessions plus
facile. Regardons l'implémentation:
Démarrage

Démarrage

• Une Session représente une conversation entre
l'application et l'entrepôt de persistance. Encapsule
une connexion JDBC. Pour le moment, nous allons
faire les choses simplement et assumer une
granularité un-un entre une Session hibernate et
une transaction à la base de données. Pour isoler
notre code du système de transaction sous-jacent
(dans notre cas,du pure JDBC,mais cela pourrait
être JTA), nous utilisons l'API Transaction qui est
disponible depuis la Session Hibernate.
Charger et stocker des objets

Charger et stocker des objets
la Session Hibernate devrait-elle être utilisée pour
exécuter une ou plusieurs opérations en base de
données ?
Le scope d'une Session Hibernate est flexible mais vous ne devriez
jamais concevoir votre application de manière à utiliser une
nouvelle Session Hibernate pour chaque opération en base de
données.

Classes persistantes
• Les classes persistantes sont les classes d'une
application qui implémentent les entités d'un
problème métier (ex. Client et Commande dans
une application de commerce électronique).
Toutes les instances d'une classe persistante ne
sont pas forcément dans l'état persistant-au lieu
de cela, une instance peut être éphémère (NdT:
transient) ou détachée.
• Hibernate fonctionne de manière optimale
lorsque ces classes suivent quelques règles
simples, aussi connues comme le modèle de
programmation Plain Old Java Object (POJO).
Cependant, aucune de ces règles ne sont des
besoins absolus.

Etats des instances
Passager (transient) : l'instance n'est pas et n'a jamais été
associée à un contexte de persistance. Elle ne possède pas
d'identité persistante (valeur de clé primaire).
Persistant: L'instance est associée au contexte de
persistance. Elle possède une identité persistante (valeur de clé
primaire) et, peut être un enregistrement correspondant dans la
base. Pour un contexte de persistance particulier, Hibernate
garantit que l'identité persistante est équivalente à l'identité
Java (emplacement mémoire de l'objet)
Détaché: l'instance a été associée au contexte de
persistance mais ce contexte a été fermé, ou l'instance a été
sérialisée vers un autre processus. Elle possède une identité
persistante et peut-être un enregistrement correspondant dans
la base. Pour des instances détachées, Hibernate ne donne
aucune garantie sur la relation entre l'identité persistante et
l'identité Java.

Règles POJO
• Implémenter un constructeur sans argument.
• Fournir une propriété d'indentifiant.
• Déclarer les accesseurs et mutateurs des attributs
persistants.
• Implémenter equals() et hashCode() : il est
recommandé d'implémenter equals() et
hashCode() en utilisant l'égalité par clé métier.

• La manière la plus évidente est d'implémenter
equals()/hashCode() en comparant la valeur
de l'identifiant des deux objets. Si cette valeur
est identique, les deux doivent représenter la
même ligne de base de données, ils sont donc
égaux ( si les deux sont ajoutés à un Set, nous
n'aurons qu'un seul élément dans le Set).
Malheureusement, nous ne pouvons pas
utiliser cette approche avec des identifiants
générés! Hibernate n'assignera de valeur
d'identifiant qu'aux objets qui sont persistants,
une instance nouvellement créée n'aura donc
pas de valeur d'identifiant !
Règles POJO

Introduction à Hibernate p.1

Contenu connexe

Tendances

En vedette

Similaire à Introduction à Hibernate p.1

Introduction à Hibernate p.1