Jede Theorie muss durch Praxis untermauert werden. Im vorherigen Kapitel haben wir den Workflow von Hibernate, Lebenszyklen und den grundlegenden Code kennengelernt, der fast immer verwendet wird. In diesem Kapitel schlage ich vor, mit der Implementierung der Interaktion zwischen der Datenbank und dem Code zu beginnen, zumindest mit den zwei Entitätsklassen, die wir derzeit haben. Wir werden das DAO-Muster verwenden, was bedeutet, dass die Logik der Interaktion mit der Datenbank von der Geschäftslogik der Anwendung getrennt wird.

HibernateUtil

Wie Sie sich vielleicht aus dem vorherigen Kapitel erinnern, verbraucht das Erstellen eines SessionFactory-Objekts viele Ressourcen. Daher müssen wir den Code optimieren, sodass dieses Objekt nur einmal während der Programmausführung erstellt wird. Wir werden dies in der Datei HibernateUtil.java tun.

Wir müssen sicherstellen, dass eine Instanz des SessionFactory-Objekts erstellt und in einer statischen Konstante gespeichert wird und nicht von anderen Dateien modifiziert wird. Dazu werden wir in dieser Klasse eine private Methode, initSessionFactory(), erstellen, die das SessionFactory-Objekt konfiguriert und erstellt. Dann weisen wir dieses Objekt der Instanz zu. Zusätzlich sollte es einen öffentlichen statischen Getter geben, sodass wir nur über diesen auf das Objekt zugreifen.

Letztendlich wird diese Klasse so aussehen:

Auf diese Weise wird das SessionFactory-Objekt nur einmal erstellt, und wir werden es verwenden, um verschiedene Sitzungen zur Manipulation von Objekten zu erstellen. Später werden wir sehen, wie man dieses Dienstprogramm korrekt verwendet.

Hinweis

Solche Dienstprogramme werden häufig in der Programmierung verwendet, um das Schreiben von Code zu erleichtern und Ressourcen zu optimieren. Wir als zukünftige Programmierer werden sie ebenfalls verwenden. Es ist eine sehr gute Praxis.

DAO-Schicht

Beginnen wir mit der Implementierung der DAO-Schicht. Nur zur Erinnerung, dies ist die Schicht, in der der Code mit der Datenbank interagiert, Daten abruft und speichert. Hier sollten wir den Code in eine Schnittstelle und eine Implementierungsklasse aufteilen. Die Schnittstelle dient als Vorlage und definiert alle Methoden, die wir implementieren müssen. Die Implementierungsklasse wird sie implementieren.

Beginnen wir mit der Employee-Entität:

Wie Sie sehen können, planen wir vorerst nur 2 Methoden zu implementieren: getById() und add(). Später, wenn wir andere Methoden für das Programm benötigen, können wir diesen Code leicht erweitern, indem wir neue Methoden zu diesem Interface hinzufügen.

Als nächstes müssen wir die Implementierung umsetzen. Sie wird sich in der EmployeeDaoImpl Klasse befinden.

Nun müssen wir die Theorie aus dem vorherigen Kapitel anwenden und sie nutzen, um diese 2 Methoden zu implementieren.

Zuerst müssen wir eine Instanz erstellen und verwenden des SessionFactory-Objekts. Wir werden dies mit dem HibernateUtil-Hilfsprogramm tun, das wir zuvor implementiert haben:

Großartig, jetzt können wir mit diesem sessionFactory Sitzungen in dieser Klasse öffnen.

Hinweis

Beachten Sie, dass die Variable private ist, was bedeutet, dass sie nur innerhalb dieser Klasse verwendet werden kann. Außerdem ist diese Variable keine neue SessionFactory; es ist eine Instanz von SessionFactory, die in der HibernateUtil-Klasse erstellt wurde.

Lassen Sie uns mit der Implementierung der add()-Methode beginnen.

Wir werden der Vorlage aus dem vorherigen Kapitel folgen:

Zunächst erstellen wir in der Methode die Variablen session und transaction und initialisieren sie als null. Dies geschieht, um den Zustand dieser Variablen besser zu verfolgen, falls Probleme auftreten, um die session zu schließen oder die transaction zurückzusetzen. Dann folgen wir dem bekannten Algorithmus:

Im catch-Block fangen wir potenzielle Fehler ab, und wenn die transaction geändert wurde, setzen wir sie zurück. Außerdem werfen wir eine neue Ausnahme, die darauf hinweist, dass wir keinen neuen Mitarbeiter hinzufügen können.

Im finally-Block überprüfen wir auch, ob das session-Objekt geändert wurde, und schließen dann die session, in der wir arbeiten.

Nun gehen wir zur Implementierung der getById-Methode über, die eine ID als Parameter nimmt und ein Element aus der Datenbank zurückgibt:

Hier ist der Algorithmus ebenfalls ähnlich und unkompliziert. Der Unterschied besteht darin, dass wir kein transaction-Objekt erstellen.

Hinweis

Eine Transaktion wird verwendet, wenn unsere Änderungen den Zustand der Tabelle in der Datenbank beeinflussen. Die meisten Abfragen aus der READ-Gruppe beeinflussen die Datenbank nicht, daher verwenden wir kein transaction-Objekt, wenn wir diese Methode implementieren.

Als nächstes folgt der vertraute Algorithmus. Falls wir eine Ausnahme abfangen, werfen wir eine neue Ausnahme, die den Benutzer darüber informiert, dass wir es nicht geschafft haben, einen Mitarbeiter nach ID abzurufen. Im finally-Block schließen wir die aktuelle Sitzung.

Hinweis

Beachten Sie, dass wir dieselbe sessionFactory-Instanz verwenden, die in dieser Datei erstellt wurde. Wir erstellen keine neue Instanz für jede Methode.

Service-Schicht

Wir haben die Interaktion des Codes mit der Datenbank in eine separate Schicht unterteilt. Es ist an der Zeit, die Service-Schicht zu schreiben, die die gesamte Geschäftslogik der Anwendung enthalten wird. Im Moment ist unsere Anwendung sehr einfach, da wir gerade lernen. Daher sollte die Service-Schicht die Methoden der DAO-Schicht nachahmen. Später, wenn sich die Anwendung entwickelt und komplexere Logik hinzugefügt wird, werden wir die Service-Schicht erweitern.

Die Service-Schicht sollte auch die Struktur von Interface - Implementierung haben.

Lassen Sie uns das EmployeeService-Interface implementieren:

Ich denke, hier gibt es nicht viel zu kommentieren; wir haben einfach die Methoden aus der DAO-Schicht in diesem Code repliziert. Im Moment sind dies die Methoden, die wir benötigen.

Nun schreiben wir die Implementierung:

Wir verwenden die Instanz des EmployeeDao-Objekts durch Komposition.

• In der add()-Methode verwenden wir einfach eine Methode aus der DAO-Schicht;
• In der getById()-Methode überprüfen wir, ob es uns gelungen ist, einen Mitarbeiter anhand der ID abzurufen, und wenn ja, geben wir dieses Objekt zurück. Wenn nicht, werfen wir eine NoSuchElementException, die anzeigt, dass wir keinen Mitarbeiter anhand der ID abrufen konnten.

Im Moment sieht die Implementierung der Service-Schicht einfach aus, aber lassen Sie uns einige zusätzliche Logik zur Anwendung hinzufügen. Zum Beispiel eine Methode, die den Namen eines Mitarbeiters anhand seiner ID abruft. Wir sollten diese Methode in der Service-Schicht implementieren, da es sich um Geschäftslogik handelt und nicht direkt die Interaktion mit der Datenbank beeinflussen sollte.

Um zu beginnen, fügen wir die Methode zur Schnittstelle hinzu:

Nun lassen Sie uns diese Methode implementieren:

• Zuerst rufen wir den Employee als Objekt mit der zuvor implementierten Methode getById ab;
• Dann erstellen wir eine Variable, um den Namen des Mitarbeiters zu speichern, indem wir den Namen mit einem Getter abrufen;
• Standardmäßige Null-Prüfung und Rückgabe des Namens des Mitarbeiters aus der Methode.

Es ist sehr wichtig, zusätzliche Logik hinzuzufügen, insbesondere auf der Service-Ebene. Ja, wir könnten die DAO-Ebene einbeziehen, aber warum zusätzliche Interaktion mit der Datenbank hinzufügen, wenn wir sie vermeiden können?

Testen der Korrektheit der Methoden.

Jetzt, da alles eingerichtet ist, können wir diese Methoden endlich verwenden.

Wir werden dies im folgenden Algorithmus tun:

1. Instanziieren Sie den EmployeeService;
2. Erstellen Sie ein neues employee-Objekt und initialisieren Sie dessen Felder mit Settern;
3. Fügen Sie den employee zur Datenbank hinzu;
4. Rufen Sie den employee nach ID ab und drucken Sie ihn auf die Konsole;
5. Rufen Sie den Namen des Mitarbeiters nach ID ab und drucken Sie ihn auf die Konsole.

Schauen wir uns die Implementierung im Code an:

Wie Sie sehen können, ist alles ganz einfach. Als Nächstes müssen wir nur noch diesen Code ausführen und damit seine Funktionalität überprüfen.

Großartig, wir haben die Datenbankverbindung für eine unserer Entitäten vollständig implementiert. Im nächsten Kapitel werden Sie die gleiche Verbindung für die Department-Entität eigenständig implementieren. Es wird eine ausgezeichnete Übung sein!