Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Lernen Implementierung der `Role`-Entity | Grundlagen von Hibernate
Java-Datenmanipulation mit Hibernate
course content

Kursinhalt

Java-Datenmanipulation mit Hibernate

Java-Datenmanipulation mit Hibernate

1. JDBC-Übersicht
2. Grundlagen von Hibernate
3. Letzte Feinabstimmungen

book
Implementierung der `Role`-Entity

Da wir unser Mitarbeiterverwaltungsprojekt korrekt gestalten möchten, sollten wir auf ein Detail achten. Zur Erinnerung, hier ist die Employee-Entität, mit der wir arbeiten:

Wie Sie sehen können, ist alles in Ordnung damit, aber mir gefällt nicht, dass die position nur ein String-Wert ist. Es wäre korrekter, eine separate "Role"-Tabelle in der Datenbank zu erstellen und dem Mitarbeiter eine ID der Rolle aus dieser Datenbank zuzuweisen. Zum Beispiel werden wir anfänglich Rollen wie Software Engineer, Project Manager, Designer und System Analyst haben.

Diese Rollen sollten in einer separaten Tabelle platziert werden, und anstelle des position-Feldes werden wir das roleID-Feld haben.

Dazu müssen wir 3 Dinge tun:

  1. Die position-Spalte löschen;
  2. Die Role-Tabelle erstellen;
  3. Eine Spalte in der Employees-Tabelle erstellen, die ein Fremdschlüssel für Role sein wird.

Hier ist die SQL-Abfrage, um dies zu tun:

Nach solchen Manipulationen wird die Tabelle Employees so aussehen:

Die Role-Tabelle wird folgendermaßen aussehen:

Wie Sie sehen können, haben wir die notwendigen Werte zur Role-Tabelle hinzugefügt. Sie haben vielleicht auch bemerkt, dass wir leere Zeilen in den Spalten department_id und role_id haben. Wir werden sie später durch den Code füllen. Jetzt müssen wir die Role-Entität implementieren und auch die Employee-Entität entsprechend bearbeiten.

Lassen Sie uns mit der Role-Entität beginnen:

Es gibt nicht viel zu kommentieren, da dies eine Standard-Entität ohne jegliche Innovationen ist.

Nun müssen wir diese Klasse zur Zuordnung hinzufügen. Dazu fügen wir diese Zeile zur Datei hibernate.cfg.xml hinzu:

Dies wird getan, damit Hibernate diese Entität automatisch erkennt, was uns die Mühe erspart, diese Klassen jedes Mal anzugeben, wenn wir eine SessionFactory erstellen.

Sehen wir uns nun an, wie wir die Employee-Entität richtig bearbeiten können, um eine unidirektionale Beziehung zur Role-Entität herzustellen:

Wir haben eine Many-to-One-Beziehung etabliert, wobei wir davon ausgehen, dass in unserem System ein Mitarbeiter nur eine Rolle haben kann. Eine Rolle kann jedoch mehreren Mitarbeitern zugewiesen werden. Zusätzlich haben wir eine Spalte zur employees-Tabelle hinzugefügt, um die Erstellung einer neuen Verbindungstabelle zu vermeiden. Großartig.

Lassen Sie uns alle Mitarbeiter abrufen, um zu überprüfen, ob derzeit alles korrekt funktioniert:

Nun sind wir daran interessiert, Standard-CRUD-Operationen für die Role-Entität in den DAO- und Service-Schichten zu implementieren. Ich überlasse Ihnen diese Aufgabe für das nächste Kapitel, da Sie dies schon oft gemacht haben und ich denke, dass es kein Problem für Sie sein wird.

Abteilungsaktualisierung

Derzeit hat keiner unserer Mitarbeiter eine Abteilung zugewiesen. Lassen Sie uns das beheben. Dazu schreiben wir Code, der einer Mitarbeiterentität basierend auf ihrer ID eine Abteilung zuweist.

Um dies zu erreichen, definieren wir eine Methode setDepartmentById() im EmployeeDao-Interface. Diese Methode akzeptiert zwei Identifikatoren: den Identifikator des Mitarbeiters und den der Abteilung. Die Methode sollte den modifizierten Mitarbeiter zurückgeben:

Nun müssen wir diese Methode in der EmployeeDaoImpl-Klasse implementieren.

Hier ist der Aktionsplan, wie wir dies umsetzen werden:

  1. Öffnen Sie eine session;
  2. Beginnen Sie eine transaction (da wir einige Änderungen an der Datenbank vornehmen werden);
  3. Rufen Sie den Mitarbeiter anhand der ID aus den Parametern mit der zuvor geschriebenen getById()-Methode ab;
  4. Rufen Sie die Abteilung anhand der ID aus den Parametern mit der getById()-Methode aus dem DepartmentService-Interface ab;
  5. Weisen Sie die abgerufene Abteilung dem Mitarbeiter mit der setDepartment()-Methode zu;
  6. Rufen Sie die merge()-Methode auf dem session-Objekt auf und übergeben Sie den employee, den wir aktualisieren möchten, als Parameter;
  7. Rufen Sie transaction.commit() auf, um die Änderungen in der Datenbank zu speichern;
  8. Behandeln Sie Fehler und schließen Sie die session wie gewohnt.

Der Code wird folgendermaßen aussehen:

Wie Sie sehen können, sieht das überhaupt nicht schwierig aus; so werden Update-Operationen in der DAO-Schicht implementiert. Nun lassen Sie uns diese Methode in der Service-Schicht implementieren, nachdem wir diese Methode im EmployeeService-Interface erstellt haben.

Die Implementierung dieser Methode wird folgendermaßen aussehen:

Zu Testzwecken weisen wir einem department mit der ID 1 eine employee mit der ID 1 zu, und nach dem Aufruf der Methode sieht das Mitarbeiterobjekt folgendermaßen aus:

Die Abteilung wurde erfolgreich hinzugefügt, und das employee-Objekt wurde in der Datenbank aktualisiert.

Methodenüberladung

Kommen wir nun zu etwas Interessanterem. Es wird nicht immer bequem sein, eine Abteilung anhand ihrer ID zuzuweisen; es wäre viel bequemer, eine Abteilung direkt als Objekt zuzuweisen.

Um dies zu implementieren, können wir die Methode überladen:

Wir werden dies in der Service-Schicht tun!

Lassen Sie uns mit der ersten Überladung fortfahren, und der Algorithmus unserer Aktionen wird folgendermaßen aussehen:

  1. Führen Sie eine Null-Prüfung durch und werfen Sie eine NullPointerException, wenn true;
  2. Rufen Sie alle Abteilungen in einer Liste ab, um später zu überprüfen, ob die angegebene Abteilung in der Datenbank existiert;
  3. Wenn die Abteilung nicht in der Datenbank gefunden wird, werfen Sie eine NoSuchElementException;
  4. Wenn die Abteilung in der Datenbank gefunden wird, verwenden Sie die Methode setDepartmentById, nachdem Sie die Abteilungs-ID mit getId() abgerufen haben.

Die endgültige Implementierung einer solchen Methode würde folgendermaßen aussehen:

Lassen Sie uns diese Methode testen:

Nach dem Testen einer solchen Methode und der Zuordnung der Personalabteilung zum zweiten Mitarbeiter sieht der Mitarbeiter so aus:

Hinweis

Es ist erwähnenswert, dass wir, um die Methode zu überladen, sie zuerst im Interface überladen und dann in der implementierenden Klasse implementieren müssen.

Großartig, jetzt können wir dem department-Objekt problemlos Employee zuweisen oder aktualisieren. Ich hoffe, Sie haben alles aufgenommen, denn im nächsten Kapitel müssen Sie dasselbe für die Role Entität implementieren.

1. Welche Änderung wird für das "position"-Attribut in der Employee-Entität vorgeschlagen?

2. Nach der Änderung der Employee-Tabelle, was stellt die Spalte "role_id" dar?

3. Was ist der Hauptvorteil der Überladung der setDepartmentById-Methode, um ein Department-Objekt direkt zu akzeptieren?

Welche Änderung wird für das "position"-Attribut in der `Employee`-Entität vorgeschlagen?

Welche Änderung wird für das "position"-Attribut in der Employee-Entität vorgeschlagen?

Wählen Sie die richtige Antwort aus

Nach der Änderung der `Employee`-Tabelle, was stellt die Spalte "role_id" dar?

Nach der Änderung der Employee-Tabelle, was stellt die Spalte "role_id" dar?

Wählen Sie die richtige Antwort aus

Was ist der Hauptvorteil der Überladung der `setDepartmentById`-Methode, um ein `Department`-Objekt direkt zu akzeptieren?

Was ist der Hauptvorteil der Überladung der setDepartmentById-Methode, um ein Department-Objekt direkt zu akzeptieren?

Wählen Sie die richtige Antwort aus

War alles klar?

Wie können wir es verbessern?

Danke für Ihr Feedback!

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