Contenu du cours
Manipulation des Données Java avec Hibernate
Manipulation des Données Java avec Hibernate
Implémentation de l'Entité `Role`
Puisque nous voulons que notre projet de gestion des employés soit correct, nous devrions prêter attention à un détail. Juste pour vous rappeler, voici l'entité Employee
avec laquelle nous travaillons :
Comme vous pouvez le voir, tout va bien avec cela, mais je n'aime pas que le position
soit juste une valeur de chaîne. Il serait plus correct de créer une table "Role" séparée dans la base de données et d'attribuer à l'employé un ID du rôle de cette base de données. Par exemple, initialement, nous aurons des rôles tels que Ingénieur Logiciel, Chef de Projet, Designer et Analyste Système.
Ces rôles devraient être placés dans une table séparée, et au lieu du champ position
, nous aurons le champ roleID
.
Pour ce faire, nous devons faire 3 choses :
- Supprimer la colonne
position
; - Créer la table
Role
; - Créer une colonne dans la table
Employees
qui sera une clé étrangère pourRole
.
Voici la requête SQL pour le faire :
Après de telles manipulations, la table Employees
ressemblera à ceci :
La table Role
ressemblera à ceci :
Comme vous pouvez le voir, nous avons ajouté les valeurs nécessaires à la table Role
. Vous avez peut-être également remarqué que nous avons des lignes vides dans les colonnes department_id
et role_id
. Nous les remplirons par le code plus tard. Pour l'instant, nous devons implémenter l'entité Role
et également modifier l'entité Employee
en conséquence.
Commençons par l'entité Role
:
Il n'est pas nécessaire de commenter beaucoup, car c'est une entité standard sans aucune innovation.
Maintenant, nous devons ajouter cette classe au mappage. Pour ce faire, nous ajouterons cette ligne au fichier hibernate.cfg.xml
:
Cela est fait pour que Hibernate détecte automatiquement cette entité, nous évitant ainsi la peine de spécifier ces classes à chaque fois que nous créons un SessionFactory
.
Voyons maintenant comment nous pouvons correctement modifier l'entité Employee
pour établir une relation unidirectionnelle avec l'entité Role
:
Nous avons établi une relation Many-to-One, en supposant que dans notre système, un employé ne peut avoir qu'un seul rôle. Cependant, un rôle peut être attribué à plusieurs employés. De plus, nous avons ajouté une colonne à la table employees
pour éviter de créer une nouvelle table de jonction. Parfait.
Retrouvons tous les employés pour vérifier si tout fonctionne correctement actuellement :
Nous sommes maintenant intéressés par la mise en œuvre des opérations CRUD standard pour l'entité Role
dans les couches DAO et Service. Je vous laisse cette tâche pour le prochain chapitre, car vous l'avez déjà fait plusieurs fois auparavant, et je ne pense pas que cela posera un problème pour vous.
Mise à jour du département
Actuellement, aucun de nos employés n'a de département assigné. Corrigeons cela. Pour ce faire, nous allons écrire du code qui assigne un département à un employé en fonction de son ID.
Pour y parvenir, définissons une méthode setDepartmentById()
dans l'interface EmployeeDao
. Cette méthode acceptera deux identifiants : l'identifiant de l'employé et l'identifiant du département. La méthode doit retourner l'employé modifié :
Nous devons maintenant implémenter cette méthode dans la classe EmployeeDaoImpl
.
Voici le plan d'action pour l'implémenter :
- Ouvrir une
session
; - Commencer une
transaction
(puisque nous allons apporter des modifications à la base de données) ; - Récupérer l'employé par ID à partir des paramètres en utilisant la méthode
getById()
précédemment écrite ; - Récupérer le département par ID à partir des paramètres en utilisant la méthode
getById()
de l'interfaceDepartmentService
; - Assigner le département récupéré à l'employé en utilisant la méthode
setDepartment()
; - Appeler la méthode
merge()
sur l'objetsession
, en passant l'employee
que nous voulons mettre à jour en paramètre ; - Appeler
transaction.commit()
pour enregistrer les modifications dans la base de données ; - Gérer les erreurs et fermer la
session
comme d'habitude.
Le code ressemblera à ceci :
Comme vous pouvez le voir, cela ne semble pas du tout difficile ; c'est ainsi que les opérations de mise à jour sont implémentées dans la couche DAO. Maintenant, implémentons cette méthode dans la couche Service, après avoir créé cette méthode dans l'interface EmployeeService
.
L'implémentation de cette méthode ressemblera à ceci :
À des fins de test, attribuons un department
avec l'identifiant 1 à un employee
avec l'identifiant 1, et après avoir appelé la méthode, l'objet employé ressemblera à ceci :
Le département a été ajouté avec succès, et l'objet employee
a été mis à jour dans la base de données.
Surcharge de Méthode
Passons maintenant à quelque chose de plus intéressant. Il ne sera pas toujours pratique pour nous d'assigner un département par son ID; il serait beaucoup plus pratique d'assigner directement un département en tant qu'objet.
Pour implémenter cela, nous pouvons surcharger la méthode :
Nous ferons cela dans la couche de service !
Passons à la première surcharge, et l'algorithme de nos actions ressemblera à ceci :
- Effectuer un contrôle de nullité, en lançant une
NullPointerException
sitrue
; - Récupérer tous les départements dans une liste pour vérifier plus tard si le département spécifié existe dans la base de données;
- Si le département n'est pas trouvé dans la base de données, lancer une
NoSuchElementException
; - Si le département est trouvé dans la base de données, utiliser la méthode
setDepartmentById
après avoir récupéré l'identifiant du département avecgetId()
.
L'implémentation finale d'une telle méthode ressemblerait à ceci :
Testons cette méthode :
Après avoir testé une telle méthode et attribué le département Ressources Humaines au deuxième employé, l'employé ressemblera à ceci :
Remarque
Il est important de mentionner que pour surcharger la méthode, nous devons la surcharger d'abord dans l'interface puis l'implémenter dans la classe d'implémentation.
Super, maintenant nous pouvons facilement assigner ou mettre à jour le department
pour un objet Employee
. J'espère que vous avez tout assimilé car, dans le prochain chapitre, vous devrez implémenter la même chose pour l'entité Role
.
1. Quelle modification est suggérée pour l'attribut "position" dans l'entité Employee
?
2. Après avoir modifié la table Employee
, que représente la colonne "role_id" ?
3. Quel est l'avantage principal de surcharger la méthode setDepartmentById
pour accepter directement un objet Department
?
Merci pour vos commentaires !