Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Apprendre Implémentation de l'Entité `Role` | Fondamentaux de Hibernate
Manipulation des Données Java avec Hibernate
course content

Contenu du cours

Manipulation des Données Java avec Hibernate

Manipulation des Données Java avec Hibernate

1. Aperçu de JDBC
2. Fondamentaux de Hibernate
3. Dernières Retouches

book
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 :

  1. Supprimer la colonne position ;
  2. Créer la table Role ;
  3. Créer une colonne dans la table Employees qui sera une clé étrangère pour Role.

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 :

  1. Ouvrir une session ;
  2. Commencer une transaction (puisque nous allons apporter des modifications à la base de données) ;
  3. Récupérer l'employé par ID à partir des paramètres en utilisant la méthode getById() précédemment écrite ;
  4. Récupérer le département par ID à partir des paramètres en utilisant la méthode getById() de l'interface DepartmentService ;
  5. Assigner le département récupéré à l'employé en utilisant la méthode setDepartment() ;
  6. Appeler la méthode merge() sur l'objet session, en passant l'employee que nous voulons mettre à jour en paramètre ;
  7. Appeler transaction.commit() pour enregistrer les modifications dans la base de données ;
  8. 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 :

  1. Effectuer un contrôle de nullité, en lançant une NullPointerException si true;
  2. 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;
  3. Si le département n'est pas trouvé dans la base de données, lancer une NoSuchElementException;
  4. 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 avec getId().

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 ?

Quelle modification est suggérée pour l'attribut "position" dans l'entité `Employee` ?

Quelle modification est suggérée pour l'attribut "position" dans l'entité Employee ?

Sélectionnez la réponse correcte

Après avoir modifié la table `Employee`, que représente la colonne "role_id" ?

Après avoir modifié la table Employee, que représente la colonne "role_id" ?

Sélectionnez la réponse correcte

Quel est l'avantage principal de surcharger la méthode `setDepartmentById` pour accepter directement un objet `Department` ?

Quel est l'avantage principal de surcharger la méthode setDepartmentById pour accepter directement un objet Department ?

Sélectionnez la réponse correcte

Tout était clair ?

Comment pouvons-nous l'améliorer ?

Merci pour vos commentaires !

Section 2. Chapitre 10
We're sorry to hear that something went wrong. What happened?
some-alt